<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:AR="http://autosar.org/2.1.4" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://autosar.org/2.1.4" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<!--
Document Title: AUTOSAR Schema Definition
Document Owner: AUTOSAR GbR
Document Version: 2.1.4
Document Status: Draft
Part of Release: 2.1
Revision: 0018
-->
	<!--
DISCLAIMER
Any use of these specifications requires membership within the AUTOSAR Development 
Partnership or an agreement with the AUTOSAR Development Partnership. The AUTOSAR 
Development Partnership will not be liable for any use of these specifications.
Following the completion of the development of the AUTOSAR specifications commercial 
exploitation licenses will be made available to end users by way of written License 
Agreement only.
No part of this publication may be reproduced or utilized in any form or by any means, 
electronic or mechanical, including photocopying and microfilm, without permission in 
writing from the publisher.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.

Copyright  2004-2007 AUTOSAR Development Partnership. All rights reserved.
-->
	<!--
ADVICE TO USERES OF AUTOSAR SPECIFICATION DOCUMENTS:
AUTOSAR Specification Documents may contain exemplary items (exemplary reference models,
"use cases", and/or references to exemplary technical solutions, devices, processes 
or software).
Any such exemplary items are contained in the Specification Documents for illustration
purposes only, and they themselves are not part of the AUTOSAR Standard. Neither their 
presence in such Specification Documents, nor any later documentation of AUTOSAR 
conformance of products actually implementing such exemplary items, imply that 
intellectual property rights covering such exemplary items are licensed under the same 
rules as applicable to the AUTOSAR Standard.
-->
	<!--
COMPATIBILITY CONSIDERATIONS WITH RESPECT TO CURRENT RELEASE
See release notes of AUTOSAR specifications which describe AUTOSAR templates
-->
	<!--
ERRATA AND KNOWN DEFICIENCIES
See release notes of AUTOSAR specifications, which describe AUTOSAR templates
-->
	<!--
KNOWN AND POTENTIAL PROBLEMS RESULTING FROM KNOWN DEFICIENCIES
See release notes of AUTOSAR specifications, which describe AUTOSAR templates
-->
	<!--
CHANGES PLANNED FOR NEXT RELEASE
The following changes are planned for the next releases: 
•	Harmonization of modeling patterns between templates
•	Add semantic constraints
•	Cleanup
Please note that the planned changes are likely to break backwards compatibility. 
See also release notes of AUTOSAR specifications, which describe AUTOSAR templates.
-->
	<!--
CHANGES SINCE LAST RELEASE
•	Legal disclaimer revised
•	Release Notes added
•	“Advice for users” revised
•	“Revision Information” added
See change notes of AUTOSAR specifications, which describe "AUTOSAR templates" and "Model Persistence Rules for XML"
-->
	<!-- 
  Changes since AUTOSAR Release 2.1 revision 16:
  * namespace increased to 2.1.4 in order to indicate changes in the metamodel
  * instanceReference from ECUConfiguration description into upstream templates fixed (RFC 19386)
  * Fixed Broken references in Gateway description of System Template (RFC 21160)
  * Fixed Typo in reference to DataWriteAccess-DataElement: dataElemement => dataElement  (RFC 21959)

-->
	<!-- $Id: $ -->
	<!-- Generated with AUTOSAR MMT on Nov 06 11:31:00 CEST 2007 v1.0.0 -->
	<!-- Generated out of Metamodel v2.1 13487  svnURL https://svn2.autosar.org/repos2/09_WorkPackages/53_WPII-5.3/02_Documents/21_Release2.1/059_AUTOSAR_MetaModel/AUTOSAR_MetaModel.EAP -->
	<!-- attribute group for class Infrastructure::ARObject -->
	<xsd:attributeGroup name="AR-OBJECT">
		<xsd:annotation>
			<xsd:documentation>
			Implicit base class of all classes in metamodel.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:attribute name="S" type="xsd:string">
			<xsd:annotation>
				<xsd:documentation>
			checksum calculated from the 
* attributes
* aggregations and aggregated non-identifiables
* references
		</xsd:documentation>
				<xsd:appinfo source="tags">
		   			xml.attribute="true";xml.name="S"
		  	 </xsd:appinfo>
			</xsd:annotation>
		</xsd:attribute>
		<xsd:attribute name="T" type="xsd:dateTime">
			<xsd:annotation>
				<xsd:documentation>
			the timestamp of the creation or modification of an instance, its attributes, references or aggregated non-identifiables.
		</xsd:documentation>
				<xsd:appinfo source="tags">
		   			xml.attribute="true";xml.name="T"
		  	 </xsd:appinfo>
			</xsd:annotation>
		</xsd:attribute>
	</xsd:attributeGroup>
	<!-- element group for class Autosar::ARPackage -->
	<xsd:group name="AR-PACKAGE">
		<xsd:annotation>
			<xsd:documentation>
			AUTOSAR package, allowing to create top level packages to structure the contained ARElements.

ARPackages are open sets, which means that in a file based description system, multiple files can be used to partially describe the contents of a package.

This is an extended version of MSR&apos;s SW-SYSTEM.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ELEMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ADC" type="AR:ADC"/>
						<xsd:element name="ACTUATOR-HW" type="AR:ACTUATOR-HW"/>
						<xsd:element name="ARRAY-TYPE" type="AR:ARRAY-TYPE"/>
						<xsd:element name="ATOMIC-SOFTWARE-COMPONENT-TYPE" type="AR:ATOMIC-SOFTWARE-COMPONENT-TYPE"/>
						<xsd:element name="BOOLEAN-TYPE" type="AR:BOOLEAN-TYPE"/>
						<xsd:element name="BSW-MODULE-DESCRIPTION" type="AR:BSW-MODULE-DESCRIPTION"/>
						<xsd:element name="CCU" type="AR:CCU"/>
						<xsd:element name="CALPRM-COMPONENT-TYPE" type="AR:CALPRM-COMPONENT-TYPE"/>
						<xsd:element name="CALPRM-INTERFACE" type="AR:CALPRM-INTERFACE"/>
						<xsd:element name="CHAR-TYPE" type="AR:CHAR-TYPE"/>
						<xsd:element name="CLIENT-SERVER-INTERFACE" type="AR:CLIENT-SERVER-INTERFACE"/>
						<xsd:element name="CLOCK" type="AR:CLOCK"/>
						<xsd:element name="COMM-PROTOCOL-TYPE" type="AR:COMM-PROTOCOL-TYPE"/>
						<xsd:element name="COMMUNICATION-MATRIX-TYPE" type="AR:COMMUNICATION-MATRIX-TYPE"/>
						<xsd:element name="COMMUNICATION-PERIPHERAL" type="AR:COMMUNICATION-PERIPHERAL"/>
						<xsd:element name="COMMUNICATION-TRANSCEIVER" type="AR:COMMUNICATION-TRANSCEIVER"/>
						<xsd:element name="COMPOSITION-TYPE" type="AR:COMPOSITION-TYPE"/>
						<xsd:element name="COMPU-METHOD" type="AR:COMPU-METHOD"/>
						<xsd:element name="CONSTANT-SPECIFICATION" type="AR:CONSTANT-SPECIFICATION"/>
						<xsd:element name="DAC" type="AR:DAC"/>
						<xsd:element name="DATA-CONSTR" type="AR:DATA-CONSTR"/>
						<xsd:element name="DIGITAL-IO" type="AR:DIGITAL-IO"/>
						<xsd:element name="DISCRETE-ECU-ELECTRONICS" type="AR:DISCRETE-ECU-ELECTRONICS"/>
						<xsd:element name="DISPLAY-HW" type="AR:DISPLAY-HW"/>
						<xsd:element name="ECU" type="AR:ECU"/>
						<xsd:element name="ECU-CONFIGURATION" type="AR:ECU-CONFIGURATION"/>
						<xsd:element name="ECU-PARAMETER-DEFINITION" type="AR:ECU-PARAMETER-DEFINITION"/>
						<xsd:element name="ECU-SW-COMPOSITION" type="AR:ECU-SW-COMPOSITION"/>
						<xsd:element name="ECUC-ELEMENT" type="AR:ECUC-ELEMENT"/>
						<xsd:element name="GATEWAY-TYPE" type="AR:GATEWAY-TYPE"/>
						<xsd:element name="HW-CONTAINER" type="AR:HW-CONTAINER"/>
						<xsd:element name="IMPLEMENTATION" type="AR:IMPLEMENTATION"/>
						<xsd:element name="INTEGER-TYPE" type="AR:INTEGER-TYPE"/>
						<xsd:element name="INTERNAL-BEHAVIOR" type="AR:INTERNAL-BEHAVIOR"/>
						<xsd:element name="MODE-DECLARATION-GROUP" type="AR:MODE-DECLARATION-GROUP"/>
						<xsd:element name="MODULE-CONFIGURATION" type="AR:MODULE-CONFIGURATION"/>
						<xsd:element name="MODULE-DEF" type="AR:MODULE-DEF"/>
						<xsd:element name="OPAQUE-TYPE" type="AR:OPAQUE-TYPE"/>
						<xsd:element name="OSCILLATOR" type="AR:OSCILLATOR"/>
						<xsd:element name="PDU-TYPE" type="AR:PDU-TYPE"/>
						<xsd:element name="PWD" type="AR:PWD"/>
						<xsd:element name="PWM" type="AR:PWM"/>
						<xsd:element name="PERIPHERAL" type="AR:PERIPHERAL"/>
						<xsd:element name="PHYSICAL-DIMENSION" type="AR:PHYSICAL-DIMENSION"/>
						<xsd:element name="POWER-DRIVER-HW-ELEMENT" type="AR:POWER-DRIVER-HW-ELEMENT"/>
						<xsd:element name="POWER-SUPPLY-HW-ELEMENT" type="AR:POWER-SUPPLY-HW-ELEMENT"/>
						<xsd:element name="PROCESSING-UNIT" type="AR:PROCESSING-UNIT"/>
						<xsd:element name="PROVIDED-MEMORY-SEGMENT" type="AR:PROVIDED-MEMORY-SEGMENT"/>
						<xsd:element name="PROVIDED-NV-MEMORY-SEGMENT" type="AR:PROVIDED-NV-MEMORY-SEGMENT"/>
						<xsd:element name="REAL-TYPE" type="AR:REAL-TYPE"/>
						<xsd:element name="RECORD-TYPE" type="AR:RECORD-TYPE"/>
						<xsd:element name="SENDER-RECEIVER-INTERFACE" type="AR:SENDER-RECEIVER-INTERFACE"/>
						<xsd:element name="SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE" type="AR:SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE"/>
						<xsd:element name="SENSOR-HW" type="AR:SENSOR-HW"/>
						<xsd:element name="SERVICE-COMPONENT-TYPE" type="AR:SERVICE-COMPONENT-TYPE"/>
						<xsd:element name="STRING-TYPE" type="AR:STRING-TYPE"/>
						<xsd:element name="SW-ADDR-METHOD" type="AR:SW-ADDR-METHOD"/>
						<xsd:element name="SW-AXIS-TYPE" type="AR:SW-AXIS-TYPE"/>
						<xsd:element name="SW-BASE-TYPE" type="AR:SW-BASE-TYPE"/>
						<xsd:element name="SW-CALPRM" type="AR:SW-CALPRM"/>
						<xsd:element name="SW-CODE-SYNTAX" type="AR:SW-CODE-SYNTAX"/>
						<xsd:element name="SW-RECORD-LAYOUT" type="AR:SW-RECORD-LAYOUT"/>
						<xsd:element name="SW-VARIABLE" type="AR:SW-VARIABLE"/>
						<xsd:element name="SYSTEM" type="AR:SYSTEM"/>
						<xsd:element name="SYSTEM-SIGNAL" type="AR:SYSTEM-SIGNAL"/>
						<xsd:element name="SYSTEM-SIGNAL-GROUP" type="AR:SYSTEM-SIGNAL-GROUP"/>
						<xsd:element name="SYSTEM-TOPOLOGY-TYPE" type="AR:SYSTEM-TOPOLOGY-TYPE"/>
						<xsd:element name="TIMER" type="AR:TIMER"/>
						<xsd:element name="UNIT" type="AR:UNIT"/>
						<xsd:element name="WATCH-DOG" type="AR:WATCH-DOG"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SUB-PACKAGES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="AR-PACKAGE" type="AR:AR-PACKAGE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Autosar::ARPackage -->
	<xsd:complexType name="AR-PACKAGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			AUTOSAR package, allowing to create top level packages to structure the contained ARElements.

ARPackages are open sets, which means that in a file based description system, multiple files can be used to partially describe the contents of a package.

This is an extended version of MSR&apos;s SW-SYSTEM.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:AR-PACKAGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Autosar::AUTOSAR -->
	<xsd:group name="AUTOSAR">
		<xsd:annotation>
			<xsd:documentation>
			Root element of an AUTOSAR description, also the root element in corresponding XML documents.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			admin.documentOwner="AUTOSAR GbR";admin.documentStatus="Draft";admin.documentTitle="Metamodel";admin.documentVersion="2.1.4";admin.partOfRelease="2.1";admin.revision="0018";xml.globalElement="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ADMIN-DATA" type="AR:ADMIN-DATA" minOccurs="0"/>
			<xsd:element name="TOP-LEVEL-PACKAGES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="AR-PACKAGE" type="AR:AR-PACKAGE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Autosar::AUTOSAR -->
	<xsd:complexType name="AUTOSAR" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Root element of an AUTOSAR description, also the root element in corresponding XML documents.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			admin.documentOwner="AUTOSAR GbR";admin.documentStatus="Draft";admin.documentTitle="Metamodel";admin.documentVersion="2.1.4";admin.partOfRelease="2.1";admin.revision="0018";xml.globalElement="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:AUTOSAR"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- global element for class Autosar::AUTOSAR -->
	<xsd:element name="AUTOSAR" type="AR:AUTOSAR">
		<xsd:annotation>
			<xsd:documentation>
			Root element of an AUTOSAR description, also the root element in corresponding XML documents.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			admin.documentOwner="AUTOSAR GbR";admin.documentStatus="Draft";admin.documentTitle="Metamodel";admin.documentVersion="2.1.4";admin.partOfRelease="2.1";admin.revision="0018";xml.globalElement="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
	</xsd:element>
	<!-- element group for class Identifiable::Identifiable -->
	<xsd:group name="IDENTIFIABLE">
		<xsd:annotation>
			<xsd:documentation>
			Instances of this class can be referred to by their identifier (while adhering to namespace borders).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SHORT-NAME" type="AR:IDENTIFIER">
				<xsd:annotation>
					<xsd:documentation>
			Use &lt;shortName&gt; to generate a short name for the context element, which enables it to be ** .
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			xml.enforceMinMultiplicity="true";xml.sequenceOffset="-100"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="LONG-NAME" type="AR:ML-DATA-4" minOccurs="0"/>
			<xsd:element name="DESC" type="AR:ML-DATA-2" minOccurs="0"/>
			<xsd:element name="CATEGORY" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element assigns a category to the parent element. The category can be used by a semantic checker in post-processes to ensure that the parent object is defined correctly i.e. has the right number of elements for example.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			xml.sequenceOffset="-50"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ADMIN-DATA" type="AR:ADMIN-DATA" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- attribute group for class Identifiable::Identifiable -->
	<xsd:attributeGroup name="IDENTIFIABLE">
		<xsd:annotation>
			<xsd:documentation>
			Instances of this class can be referred to by their identifier (while adhering to namespace borders).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:attribute name="UUID" type="xsd:string">
			<xsd:annotation>
				<xsd:documentation>
			The purpose of this attribute is to provide a globally unique identifier for an instance of a metaclass. The values of this attribute should be globally unique strings prefixed by the type of identifier.  For example, to include a
DCE UUID as defined by The Open Group, the UUID would be preceded by &quot;DCE:&quot;. The values of this attribute may be used to support merging of different AUTOSAR models. 
The form of the UUID (Universally Unique Identifier) is taken from a standard defined by the Open Group (was Open Software Foundation). This standard is widely used, including by Microsoft for COM (GUIDs) and by many companies for DCE, which is based on CORBA. The method for generating these 128-bit IDs is published in the standard and the effectiveness and uniqueness of the IDs is not in practice disputed.
If the id namespace is omitted, DCE is assumed. 
An example is &quot;DCE:2fac1234-31f8-11b4-a222-08002b34c003&quot;.
		</xsd:documentation>
				<xsd:appinfo source="tags">
		   			xml.attribute="true"
		  	 </xsd:appinfo>
			</xsd:annotation>
		</xsd:attribute>
	</xsd:attributeGroup>
	<xsd:simpleType name="IDENTIFIABLE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ADC"/>
			<xsd:enumeration value="AR-PACKAGE"/>
			<xsd:enumeration value="ACTUATOR-HW"/>
			<xsd:enumeration value="APPLICATION-ERROR"/>
			<xsd:enumeration value="ARGUMENT-PROTOTYPE"/>
			<xsd:enumeration value="ARRAY-ELEMENT"/>
			<xsd:enumeration value="ARRAY-SPECIFICATION"/>
			<xsd:enumeration value="ARRAY-TYPE"/>
			<xsd:enumeration value="ASSEMBLY-CONNECTOR-PROTOTYPE"/>
			<xsd:enumeration value="ASSEMBLY-HW-CONNECTION"/>
			<xsd:enumeration value="ASYNCHRONOUS-SERVER-CALL-POINT"/>
			<xsd:enumeration value="ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT"/>
			<xsd:enumeration value="ATOMIC-SOFTWARE-COMPONENT-TYPE"/>
			<xsd:enumeration value="BOOLEAN-LITERAL"/>
			<xsd:enumeration value="BOOLEAN-PARAM-DEF"/>
			<xsd:enumeration value="BOOLEAN-TYPE"/>
			<xsd:enumeration value="BSW-MODULE-DESCRIPTION"/>
			<xsd:enumeration value="CAN-BUS"/>
			<xsd:enumeration value="CAN-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:enumeration value="CCU"/>
			<xsd:enumeration value="CALPRM-ACCESS"/>
			<xsd:enumeration value="CALPRM-COMPONENT-TYPE"/>
			<xsd:enumeration value="CALPRM-ELEMENT-PROTOTYPE"/>
			<xsd:enumeration value="CALPRM-INTERFACE"/>
			<xsd:enumeration value="CAN-FRAME"/>
			<xsd:enumeration value="CAPTION"/>
			<xsd:enumeration value="CHAR-LITERAL"/>
			<xsd:enumeration value="CHAR-TYPE"/>
			<xsd:enumeration value="CHOICE-CONTAINER-DEF"/>
			<xsd:enumeration value="CHOICE-REFERENCE-DEF"/>
			<xsd:enumeration value="CLIENT-SERVER-INTERFACE"/>
			<xsd:enumeration value="CLOCK"/>
			<xsd:enumeration value="CLUSTER-SIGNAL"/>
			<xsd:enumeration value="CODE"/>
			<xsd:enumeration value="COMM-PROTOCOL-ELEMENT"/>
			<xsd:enumeration value="COMM-PROTOCOL-FRAME-ROLE"/>
			<xsd:enumeration value="COMM-PROTOCOL-INSTANCE"/>
			<xsd:enumeration value="COMM-PROTOCOL-SIGNAL-GROUP-ROLE"/>
			<xsd:enumeration value="COMM-PROTOCOL-SIGNAL-ROLE"/>
			<xsd:enumeration value="COMM-PROTOCOL-TYPE"/>
			<xsd:enumeration value="COMMUNICATION-HW-PORT"/>
			<xsd:enumeration value="COMMUNICATION-MATRIX-INSTANCE"/>
			<xsd:enumeration value="COMMUNICATION-MATRIX-TYPE"/>
			<xsd:enumeration value="COMMUNICATION-PERIPHERAL"/>
			<xsd:enumeration value="COMMUNICATION-PROTOCOL"/>
			<xsd:enumeration value="COMMUNICATION-TRANSCEIVER"/>
			<xsd:enumeration value="COMPILER"/>
			<xsd:enumeration value="COMPONENT-PROTOTYPE"/>
			<xsd:enumeration value="COMPOSITION-TYPE"/>
			<xsd:enumeration value="COMPU-METHOD"/>
			<xsd:enumeration value="CONNECTOR"/>
			<xsd:enumeration value="CONSTANT-REFERENCE"/>
			<xsd:enumeration value="CONSTANT-SPECIFICATION"/>
			<xsd:enumeration value="CONTAINER"/>
			<xsd:enumeration value="DAC"/>
			<xsd:enumeration value="DATA-CONSTR"/>
			<xsd:enumeration value="DATA-ELEMENT-PROTOTYPE"/>
			<xsd:enumeration value="DATA-READ-ACCESS"/>
			<xsd:enumeration value="DATA-RECEIVE-ERROR-EVENT"/>
			<xsd:enumeration value="DATA-RECEIVE-POINT"/>
			<xsd:enumeration value="DATA-RECEIVED-EVENT"/>
			<xsd:enumeration value="DATA-SEND-COMPLETED-EVENT"/>
			<xsd:enumeration value="DATA-SEND-POINT"/>
			<xsd:enumeration value="DATA-WRITE-ACCESS"/>
			<xsd:enumeration value="DELEGATION-CONNECTOR-PROTOTYPE"/>
			<xsd:enumeration value="DELEGATION-HW-CONNECTION"/>
			<xsd:enumeration value="DEPENDENCY-ON-FILE"/>
			<xsd:enumeration value="DEPENDENCY-ON-LIBRARY"/>
			<xsd:enumeration value="DERIVED-BOOLEAN-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-ENUMERATION-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-FLOAT-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-INTEGER-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-STRING-PARAM-DEF"/>
			<xsd:enumeration value="DIGITAL-IO"/>
			<xsd:enumeration value="DISCRETE-ECU-ELECTRONICS"/>
			<xsd:enumeration value="DISPLAY-HW"/>
			<xsd:enumeration value="ECU"/>
			<xsd:enumeration value="ECU-COMMUNICATION-PORT"/>
			<xsd:enumeration value="ECU-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:enumeration value="ECU-INSTANCE"/>
			<xsd:enumeration value="ECU-CONFIGURATION"/>
			<xsd:enumeration value="ECU-PARAMETER-DEFINITION"/>
			<xsd:enumeration value="ECU-SW-COMPOSITION"/>
			<xsd:enumeration value="ECUC-ELEMENT"/>
			<xsd:enumeration value="ENUMERATION-LITERAL-DEF"/>
			<xsd:enumeration value="ENUMERATION-PARAM-DEF"/>
			<xsd:enumeration value="EXCLUSIVE-AREA"/>
			<xsd:enumeration value="EXECUTION-TIME"/>
			<xsd:enumeration value="FLEXRAY-CLUSTER"/>
			<xsd:enumeration value="FLEXRAY-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:enumeration value="FLEXRAY-FRAME"/>
			<xsd:enumeration value="FLOAT-PARAM-DEF"/>
			<xsd:enumeration value="FOREIGN-REFERENCE-DEF"/>
			<xsd:enumeration value="FRAME"/>
			<xsd:enumeration value="FUNCTION-NAME-DEF"/>
			<xsd:enumeration value="GATEWAY-INSTANCE"/>
			<xsd:enumeration value="GATEWAY-TYPE"/>
			<xsd:enumeration value="HW-CONTAINER"/>
			<xsd:enumeration value="HW-PIN"/>
			<xsd:enumeration value="HW-PORT"/>
			<xsd:enumeration value="HUB"/>
			<xsd:enumeration value="IMPLEMENTATION"/>
			<xsd:enumeration value="INSTANCE-REFERENCE-DEF"/>
			<xsd:enumeration value="INTEGER-LITERAL"/>
			<xsd:enumeration value="INTEGER-PARAM-DEF"/>
			<xsd:enumeration value="INTEGER-TYPE"/>
			<xsd:enumeration value="INTER-RUNNABLE-VARIABLE"/>
			<xsd:enumeration value="INTERNAL-BEHAVIOR"/>
			<xsd:enumeration value="INTERRUPT-CONSUME-HW-PORT"/>
			<xsd:enumeration value="INTERRUPT-PRODUCE-HW-PORT"/>
			<xsd:enumeration value="LIN-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:enumeration value="LIN-SUB-BUS"/>
			<xsd:enumeration value="LIN-FRAME"/>
			<xsd:enumeration value="LIN-SCHEDULING-TABLE"/>
			<xsd:enumeration value="LINKER-SYMBOL-DEF"/>
			<xsd:enumeration value="MEASURABLE"/>
			<xsd:enumeration value="MEASURED-EXECUTION-TIME"/>
			<xsd:enumeration value="MEMORY-MAPPED-ASSEMBLY-HW-CONNECTION"/>
			<xsd:enumeration value="MEMORY-MAPPED-DELEGATION-HW-CONNECTION"/>
			<xsd:enumeration value="MEMORY-MAPPED-HW-PORT"/>
			<xsd:enumeration value="MODE-DECLARATION"/>
			<xsd:enumeration value="MODE-DECLARATION-GROUP"/>
			<xsd:enumeration value="MODE-DECLARATION-GROUP-PROTOTYPE"/>
			<xsd:enumeration value="MODE-SWITCH-EVENT"/>
			<xsd:enumeration value="MODE-SWITCH-POINT"/>
			<xsd:enumeration value="MODE-SWITCHED-ACK-EVENT"/>
			<xsd:enumeration value="MODULE-CONFIGURATION"/>
			<xsd:enumeration value="MODULE-DEF"/>
			<xsd:enumeration value="NVRAM-MAPPING"/>
			<xsd:enumeration value="OBJECT-FILE-SECTION"/>
			<xsd:enumeration value="OPAQUE-LITERAL"/>
			<xsd:enumeration value="OPAQUE-TYPE"/>
			<xsd:enumeration value="OPERATION-INVOKED-EVENT"/>
			<xsd:enumeration value="OPERATION-PROTOTYPE"/>
			<xsd:enumeration value="OSCILLATOR"/>
			<xsd:enumeration value="PDU-PROTOTYPE"/>
			<xsd:enumeration value="PDU-TYPE"/>
			<xsd:enumeration value="P-PORT-PROTOTYPE"/>
			<xsd:enumeration value="PWD"/>
			<xsd:enumeration value="PWM"/>
			<xsd:enumeration value="PARAM-CONF-CONTAINER-DEF"/>
			<xsd:enumeration value="PER-INSTANCE-MEMORY"/>
			<xsd:enumeration value="PER-INSTANCE-MEMORY-VARIABLE"/>
			<xsd:enumeration value="PERIPHERAL"/>
			<xsd:enumeration value="PERIPHERAL-HW-PORT"/>
			<xsd:enumeration value="PHYSICAL-CHANNEL"/>
			<xsd:enumeration value="PHYSICAL-DIMENSION"/>
			<xsd:enumeration value="POWER-DRIVER-HW-ELEMENT"/>
			<xsd:enumeration value="POWER-DRIVER-HW-PORT"/>
			<xsd:enumeration value="POWER-SUPPLY-HW-ELEMENT"/>
			<xsd:enumeration value="POWER-SUPPLY-HW-PORT"/>
			<xsd:enumeration value="PROCESSING-UNIT"/>
			<xsd:enumeration value="PROVIDED-MEMORY-SEGMENT"/>
			<xsd:enumeration value="PROVIDED-NV-MEMORY-SEGMENT"/>
			<xsd:enumeration value="R-PORT-PROTOTYPE"/>
			<xsd:enumeration value="REAL-LITERAL"/>
			<xsd:enumeration value="REAL-TYPE"/>
			<xsd:enumeration value="RECORD-ELEMENT"/>
			<xsd:enumeration value="RECORD-SPECIFICATION"/>
			<xsd:enumeration value="RECORD-TYPE"/>
			<xsd:enumeration value="REFERENCE-DEF"/>
			<xsd:enumeration value="RESOURCE-CONSUMPTION"/>
			<xsd:enumeration value="ROUGH-ESTIMATE-OF-EXECUTION-TIME"/>
			<xsd:enumeration value="RUNNABLE-ENTITY"/>
			<xsd:enumeration value="SENDER-RECEIVER-INTERFACE"/>
			<xsd:enumeration value="SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE"/>
			<xsd:enumeration value="SENSOR-HW"/>
			<xsd:enumeration value="SERVICE-COMPONENT-PROTOTYPE"/>
			<xsd:enumeration value="SERVICE-COMPONENT-TYPE"/>
			<xsd:enumeration value="SERVICE-CONNECTOR-PROTOTYPE"/>
			<xsd:enumeration value="SIGNAL-POSITION"/>
			<xsd:enumeration value="SIMULATED-EXECUTION-TIME"/>
			<xsd:enumeration value="SOFTWARE-COMPOSITION"/>
			<xsd:enumeration value="STD"/>
			<xsd:enumeration value="STRING-LITERAL"/>
			<xsd:enumeration value="STRING-PARAM-DEF"/>
			<xsd:enumeration value="STRING-TYPE"/>
			<xsd:enumeration value="SUPPORTED-DATA-TYPE"/>
			<xsd:enumeration value="SW-ADDR-METHOD"/>
			<xsd:enumeration value="SW-AXIS-TYPE"/>
			<xsd:enumeration value="SW-BASE-TYPE"/>
			<xsd:enumeration value="SW-CALPRM"/>
			<xsd:enumeration value="SW-CODE-SYNTAX"/>
			<xsd:enumeration value="SW-COMP-TO-ECU-MAPPING"/>
			<xsd:enumeration value="SW-COMP-TO-IMPL-MAPPING"/>
			<xsd:enumeration value="SW-GENERIC-AXIS-PARAM-TYPE"/>
			<xsd:enumeration value="SW-RECORD-LAYOUT"/>
			<xsd:enumeration value="SW-VARIABLE"/>
			<xsd:enumeration value="SYMBOLIC-NAME-REFERENCE-DEF"/>
			<xsd:enumeration value="SYNCHRONOUS-SERVER-CALL-POINT"/>
			<xsd:enumeration value="SYSTEM"/>
			<xsd:enumeration value="SYSTEM-MAPPING"/>
			<xsd:enumeration value="SYSTEM-SIGNAL"/>
			<xsd:enumeration value="SYSTEM-SIGNAL-GROUP"/>
			<xsd:enumeration value="SYSTEM-TOPOLOGY-INSTANCE"/>
			<xsd:enumeration value="SYSTEM-TOPOLOGY-TYPE"/>
			<xsd:enumeration value="TIMER"/>
			<xsd:enumeration value="TIMING-EVENT"/>
			<xsd:enumeration value="UNIT"/>
			<xsd:enumeration value="UNIT-GROUP"/>
			<xsd:enumeration value="UNSPECIFIED-CONNECTION"/>
			<xsd:enumeration value="WAIT-POINT"/>
			<xsd:enumeration value="WATCH-DOG"/>
			<xsd:enumeration value="WORST-CASE-EXECUTION-TIME"/>
			<xsd:enumeration value="XDOC"/>
			<xsd:enumeration value="XFILE"/>
			<xsd:enumeration value="XREF-TARGET"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="BYTE-ORDER-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MOST-SIGNIFICANT-BYTE-LAST"/>
			<xsd:enumeration value="MOST-SIGNIFICANT-BYTE-FIRST"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class AdminData::AdminData -->
	<xsd:group name="ADMIN-DATA">
		<xsd:annotation>
			<xsd:documentation>
			&lt;adminData&gt; can be used to set administrative information for an element. This administration information is to be treated as metadata such as revision id or state of the file. There are basically four kinds of metadata

* The language and/or used laguages.

* Revision information covering e.g. revision number, state, release date, changes. Note that this information can be given in general as well as related to a particular company.

* Document metadata specific for a company

* Formatting controls that can affect layouts for example.

* Revision information for the element.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-ADMIN-DATA";msr.id="type__ADMIN-DATA_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="LANGUAGE" type="AR:L-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			&lt;language&gt; represents the human language used within the file. Its primary use is to prompt the tools to switch to an appropriate language.

This element is in accordance with the ISO 639-1 two letter language codes ( Codes for the Representation of Names of Languages http://www.loc.gov/standards/iso639-2/langcodes.html ). The most frequently used codes are given in :

Most common language codes (alphabetical)


Code

* Language

de

* German

en

* English

es

* Spanish

fr

* French

it

* Italian

jp

* Japanese
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="ADMIN-DATA_TYPE__LANGUAGE";msr.tbdString="true";xml.sequenceOffset="20"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="USED-LANGUAGES" type="AR:ML-DATA-10" minOccurs="0"/>
			<xsd:element name="DOC-REVISIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DOC-REVISION" type="AR:DOC-REVISION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SDGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SDG" type="AR:SDG"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class AdminData::AdminData -->
	<xsd:complexType name="ADMIN-DATA" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			&lt;adminData&gt; can be used to set administrative information for an element. This administration information is to be treated as metadata such as revision id or state of the file. There are basically four kinds of metadata

* The language and/or used laguages.

* Revision information covering e.g. revision number, state, release date, changes. Note that this information can be given in general as well as related to a particular company.

* Document metadata specific for a company

* Formatting controls that can affect layouts for example.

* Revision information for the element.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-ADMIN-DATA";msr.id="type__ADMIN-DATA_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ADMIN-DATA"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class AdminData::DocRevision -->
	<xsd:group name="DOC-REVISION">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;docRevision&gt; , to generate information on the corresponding document version.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="DOC-REVISION";msr.id="type__DOC-REVISION_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="REVISION-LABEL" type="AR:ML-DATA-10" minOccurs="0"/>
			<xsd:element name="REVISION-LABEL-P-1" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Use &lt;revisionLabelP1&gt;, to enter the version number of the ** of the document, or the document section to which administrative is applied.. The syntax is free and refers to the configuration management plan respectively the version management tool being used. This element is used, if the document or document section is the result of a merge process in which two branches are merged in to one new revision.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="DOC-REVISION_TYPE__REVISION-LABEL-P1";msr.tbdString="true";xml.sequenceOffset="30"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="REVISION-LABEL-P-2" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Use &lt;revisionLabelP1&gt;, to enter the version number of the ** of the document, or the document section to which administrative is applied.. The syntax is free and refers to the configuration management plan respectively the version management tool being used. This element is used, if the document or document section is the result of a merge process in which two branches are merged in to one new revision.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="DOC-REVISION_TYPE__REVISION-LABEL-P2";msr.tbdString="true";xml.sequenceOffset="40"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="STATE" type="AR:ML-DATA-10" minOccurs="0"/>
			<xsd:element name="ISSUED-BY" type="AR:ML-DATA-10" minOccurs="0"/>
			<xsd:element name="DATE" type="AR:ML-DATA-10" minOccurs="0"/>
			<xsd:element name="MODIFICATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MODIFICATION" type="AR:MODIFICATION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class AdminData::DocRevision -->
	<xsd:complexType name="DOC-REVISION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;docRevision&gt; , to generate information on the corresponding document version.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="DOC-REVISION";msr.id="type__DOC-REVISION_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:DOC-REVISION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class AdminData::Modification -->
	<xsd:group name="MODIFICATION">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;modification&gt; to record what has changed in a document in comparison to its predecessor.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="MODIFICATION";msr.id="type__MODIFICATION_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CHANGE" type="AR:ML-DATA-2" minOccurs="0"/>
			<xsd:element name="REASON" type="AR:ML-DATA-2" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class AdminData::Modification -->
	<xsd:complexType name="MODIFICATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;modification&gt; to record what has changed in a document in comparison to its predecessor.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="MODIFICATION";msr.id="type__MODIFICATION_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MODIFICATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class AdminData::CompanyRevisionInfo -->
	<xsd:complexType name="COMPANY-REVISION-INFO" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;companyRevisionInfo&gt; , to generate information on document version within the respective company.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="COMPANY-REVISION-INFO";msr.id="type__COMPANY-REVISION-INFO_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class AdminData::CompanySpecificInfo -->
	<xsd:complexType name="COMPANY-SPECIFIC-INFO" abstract="false" mixed="false">
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CONTENT-RELATED"/>
			<xsd:enumeration value="DOC-RELATED"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- attribute group for class LanguageDataModel::L1 -->
	<xsd:attributeGroup name="L-1">
		<xsd:annotation>
			<xsd:documentation>
			ParagraphInOneParticularLanguage

This is the text for a paragraph in one particular language. The language is denoted in the attribute l.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-1_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="L" type="AR:L-ENUM"/>
	</xsd:attributeGroup>
	<!-- complex type for class LanguageDataModel::L1 -->
	<xsd:complexType name="L-1" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			ParagraphInOneParticularLanguage

This is the text for a paragraph in one particular language. The language is denoted in the attribute l.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-1_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:L-1"/>
	</xsd:complexType>
	<!-- attribute group for class LanguageDataModel::L10 -->
	<xsd:attributeGroup name="L-10">
		<xsd:annotation>
			<xsd:documentation>
			MixedContentForPlainText in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-10_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="L" type="AR:L-ENUM"/>
	</xsd:attributeGroup>
	<!-- complex type for class LanguageDataModel::L10 -->
	<xsd:complexType name="L-10" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			MixedContentForPlainText in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-10_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:L-10"/>
	</xsd:complexType>
	<!-- attribute group for class LanguageDataModel::L2 -->
	<xsd:attributeGroup name="L-2">
		<xsd:annotation>
			<xsd:documentation>
			MixedContentForOverviewParagraph in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-2_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="L" type="AR:L-ENUM"/>
	</xsd:attributeGroup>
	<!-- complex type for class LanguageDataModel::L2 -->
	<xsd:complexType name="L-2" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			MixedContentForOverviewParagraph in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-2_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:L-2"/>
	</xsd:complexType>
	<!-- attribute group for class LanguageDataModel::L3 -->
	<xsd:attributeGroup name="L-3">
		<xsd:annotation>
			<xsd:documentation>
			MixedContentForUnitNames in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-3_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="L" type="AR:L-ENUM"/>
	</xsd:attributeGroup>
	<!-- complex type for class LanguageDataModel::L3 -->
	<xsd:complexType name="L-3" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			MixedContentForUnitNames in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-3_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:L-3"/>
	</xsd:complexType>
	<!-- attribute group for class LanguageDataModel::L4 -->
	<xsd:attributeGroup name="L-4">
		<xsd:annotation>
			<xsd:documentation>
			 MixedContentForLongNames  in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-4_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="L" type="AR:L-ENUM"/>
	</xsd:attributeGroup>
	<!-- complex type for class LanguageDataModel::L4 -->
	<xsd:complexType name="L-4" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			 MixedContentForLongNames  in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-4_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:L-4"/>
	</xsd:complexType>
	<!-- attribute group for class LanguageDataModel::L5 -->
	<xsd:attributeGroup name="L-5">
		<xsd:annotation>
			<xsd:documentation>
			
MixedContentForVerbatim in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-5_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="L" type="AR:L-ENUM"/>
	</xsd:attributeGroup>
	<!-- complex type for class LanguageDataModel::L5 -->
	<xsd:complexType name="L-5" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			
MixedContentForVerbatim in one particular language. The language is dentoted in the attribute l.


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__L-5_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:L-5"/>
	</xsd:complexType>
	<!-- element group for class LanguageDataModel::MlDataModel1 -->
	<xsd:group name="ML-DATA-MODEL-1">
		<xsd:annotation>
			<xsd:documentation>
			
MultilanguageDataModelForParagraph


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-model-1";msr.isMaster="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="L-1" type="AR:L-1" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class LanguageDataModel::MlDataModel10 -->
	<xsd:group name="ML-DATA-MODEL-10">
		<xsd:annotation>
			<xsd:documentation>
			
MultilanguageDataModelForPlainText


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-model-10";msr.isMaster="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="L-10" type="AR:L-10" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class LanguageDataModel::MlDataModel2 -->
	<xsd:group name="ML-DATA-MODEL-2">
		<xsd:annotation>
			<xsd:documentation>
			MultilanguageDataModelForOverviewParagraph


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-model-2";msr.isMaster="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="L-2" type="AR:L-2" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class LanguageDataModel::MlDataModel3 -->
	<xsd:group name="ML-DATA-MODEL-3">
		<xsd:annotation>
			<xsd:documentation>
			
MultilanguageDataModelForUnitNames

		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-model-3";msr.isMaster="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="L-3" type="AR:L-3" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class LanguageDataModel::MlDataModel4 -->
	<xsd:group name="ML-DATA-MODEL-4">
		<xsd:annotation>
			<xsd:documentation>
			
MultilanguageDataModelForLongNames


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-model-4";msr.isMaster="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="L-4" type="AR:L-4" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class LanguageDataModel::MlDataModel5 -->
	<xsd:group name="ML-DATA-MODEL-5">
		<xsd:annotation>
			<xsd:documentation>
			MultilanguageDataModelForVerbatim

		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-model-5";msr.isMaster="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="L-5" type="AR:L-5" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="L-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="FR"/>
			<xsd:enumeration value="DE"/>
			<xsd:enumeration value="FOR-ALL"/>
			<xsd:enumeration value="EN"/>
			<xsd:enumeration value="IT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Inlines::Br -->
	<xsd:complexType name="BR" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element is the same as function here as in a HTML document i.e. it forces a line break.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__BR_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="E-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="BOLD"/>
			<xsd:enumeration value="PLAIN"/>
			<xsd:enumeration value="BOLDITALIC"/>
			<xsd:enumeration value="ITALIC"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="E-ENUM-FONT">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MONO"/>
			<xsd:enumeration value="DEFAULT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Inlines::EType -->
	<xsd:complexType name="E-TYPE" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			This is an emphasized text. As a compromise it contains some rendering oriented attributes such as color and font.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__E_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Inlines::Ft -->
	<xsd:complexType name="FT" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;ft&gt; , to create a footnote.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__FT_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Inlines::Ie -->
	<xsd:complexType name="IE" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;ie&gt; to create an index that is to appear in the index directory.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__IE_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="SHOW-CONTENT-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="NO-SHOW-CONTENT"/>
			<xsd:enumeration value="SHOW-CONTENT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="SHOW-RESOURCE-LONG-NAME-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SHOW-LONG-NAME"/>
			<xsd:enumeration value="NO-SHOW-LONG-NAME"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="SHOW-RESOURCE-NUMBER-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SHOW-NUMBER"/>
			<xsd:enumeration value="NO-SHOW-NUMBER"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="SHOW-RESOURCE-PAGE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="NO-SHOW-PAGE"/>
			<xsd:enumeration value="SHOW-PAGE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="SHOW-RESOURCE-SHORT-NAME-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SHOW-SHORT-NAME"/>
			<xsd:enumeration value="NO-SHOW-SHORT-NAME"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="SHOW-RESOURCE-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SHOW-TYPE"/>
			<xsd:enumeration value="NO-SHOW-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="SHOW-SEE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="NO-SHOW-SEE"/>
			<xsd:enumeration value="SHOW-SEE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Inlines::Std -->
	<xsd:complexType name="STD" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;std&gt; to reference external standards within a paragraph element.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__STD_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class Inlines::Tt -->
	<xsd:complexType name="TT" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;tt&gt; to format technical terms within the paragraph element.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__TT_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="TT-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ORGANISATION"/>
			<xsd:enumeration value="TOOL"/>
			<xsd:enumeration value="CODE"/>
			<xsd:enumeration value="STATE"/>
			<xsd:enumeration value="SGMLTAG"/>
			<xsd:enumeration value="SGML-ATTRIBUTE"/>
			<xsd:enumeration value="VARIABLE"/>
			<xsd:enumeration value="PRM"/>
			<xsd:enumeration value="MATERIAL"/>
			<xsd:enumeration value="PRODUCT"/>
			<xsd:enumeration value="CONTROL-ELEMENT"/>
			<xsd:enumeration value="OTHER"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- attribute group for class Inlines::Url -->
	<xsd:attributeGroup name="URL">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the Uniform Resource Locator (URL) of the context contained in the &lt;url&gt; element.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="URL";msr.id="type__URL_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="MIME-TYPE" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class Inlines::Url -->
	<xsd:complexType name="URL" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the Uniform Resource Locator (URL) of the context contained in the &lt;url&gt; element.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="URL";msr.id="type__URL_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:URL"/>
	</xsd:complexType>
	<!-- complex type for class Inlines::Xdoc -->
	<xsd:complexType name="XDOC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;xdoc&gt; , to reference an external document.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="XDOC";msr.id="type__XDOC_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Inlines::Xfile -->
	<xsd:group name="XFILE">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;xfile&gt; , to reference an external file.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__XFILE_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="URL" type="AR:URL" minOccurs="0"/>
			<xsd:element name="TOOL" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element describes the tool which was used to generate the corresponding &lt;xfile&gt; .
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="XFILE_TYPE__TOOL";msr.tbdString="true";xml.sequenceOffset="50"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TOOL-VERSION" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element describes the tool version which was used to generate the corresponding &lt;xfile&gt; .
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="XFILE_TYPE__TOOL-VERSION";msr.tbdString="true";xml.sequenceOffset="60"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Inlines::Xfile -->
	<xsd:complexType name="XFILE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;xfile&gt; , to reference an external file.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__XFILE_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:XFILE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class Inlines::Xref -->
	<xsd:complexType name="XREF" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;xref&gt; , to generate cross-references within the document.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__XREF_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Inlines::XrefTarget -->
	<xsd:complexType name="XREF-TARGET" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies a reference target which can be scattered throughout the text.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__XREF-TARGET_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class SpecialData::Caption -->
	<xsd:complexType name="CAPTION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- attribute group for class SpecialData::Sd -->
	<xsd:attributeGroup name="SD">
		<xsd:annotation>
			<xsd:documentation>
			This element is a &quot;Special Data&quot; element. By using this element it is possible to extend the dtd with a &quot;new&quot; element tag.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="SD";msr.id="type__SD_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="GID" type="xsd:string"/>
		<xsd:attribute name="ID-CLASS" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class SpecialData::Sd -->
	<xsd:complexType name="SD" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			This element is a &quot;Special Data&quot; element. By using this element it is possible to extend the dtd with a &quot;new&quot; element tag.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="SD";msr.id="type__SD_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:SD"/>
	</xsd:complexType>
	<!-- element group for class SpecialData::SdgContents -->
	<xsd:group name="SDG-CONTENTS">
		<xsd:choice>
			<xsd:choice minOccurs="0" maxOccurs="unbounded">
				<xsd:element name="SD" type="AR:SD" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element name="SDG" type="AR:SDG" minOccurs="0" maxOccurs="unbounded"/>
			</xsd:choice>
		</xsd:choice>
	</xsd:group>
	<!-- complex type for class SpecialData::SdgContents -->
	<xsd:complexType name="SDG-CONTENTS" abstract="false" mixed="false">
		<xsd:choice minOccurs="0" maxOccurs="unbounded">
			<xsd:group ref="AR:SDG-CONTENTS"/>
		</xsd:choice>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SpecialData::Sdgs -->
	<xsd:group name="SDGS">
		<xsd:annotation>
			<xsd:documentation>
			This is a container for one or several &lt;sdg&gt; (Special Data Group) elements.

Special data groups (SDGs) are a standard extension mechanism for harmonized objects; they are used to store data for that no other element exists of the data model in a structured way. It could be considerd as a &quot;well formed island&quot; which allows to carry specific data even if the DTD itself does not expllicitly supports it. this prevents a process designer or a user to entirely switch to another technology if information musst be transferred whichis not explicitly supported.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-SDGS";msr.id="type__SDGS_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SDG" type="AR:SDG" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SpecialData::Sdgs -->
	<xsd:complexType name="SDGS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This is a container for one or several &lt;sdg&gt; (Special Data Group) elements.

Special data groups (SDGs) are a standard extension mechanism for harmonized objects; they are used to store data for that no other element exists of the data model in a structured way. It could be considerd as a &quot;well formed island&quot; which allows to carry specific data even if the DTD itself does not expllicitly supports it. this prevents a process designer or a user to entirely switch to another technology if information musst be transferred whichis not explicitly supported.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-SDGS";msr.id="type__SDGS_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SDGS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SpecialData::Sdg -->
	<xsd:group name="SDG">
		<xsd:annotation>
			<xsd:documentation>
			&lt;sdg&gt; (Special Data Group) is a backdoor used to handle elements that has not yet been defined in a DTD. The &lt;sdg&gt; is a containder for one or several &lt;sd&gt; that defines new elements and carries the information. Special Data should only be used moderately since all elements should be defined in the dtd. Thereby should SDG be considered as a temporary sollution when elements are missing. If a &lt;sdgCaption&gt; element is created along with a &lt;shortName&gt; it is possible to reference the &lt;sdg&gt; structure via a &lt;xref&gt;.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-SDG";msr.id="type__SDG_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SDG-CAPTION" type="AR:CAPTION" minOccurs="0"/>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:SDG-CONTENTS"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- attribute group for class SpecialData::Sdg -->
	<xsd:attributeGroup name="SDG">
		<xsd:annotation>
			<xsd:documentation>
			&lt;sdg&gt; (Special Data Group) is a backdoor used to handle elements that has not yet been defined in a DTD. The &lt;sdg&gt; is a containder for one or several &lt;sd&gt; that defines new elements and carries the information. Special Data should only be used moderately since all elements should be defined in the dtd. Thereby should SDG be considered as a temporary sollution when elements are missing. If a &lt;sdgCaption&gt; element is created along with a &lt;shortName&gt; it is possible to reference the &lt;sdg&gt; structure via a &lt;xref&gt;.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-SDG";msr.id="type__SDG_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="GID" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class SpecialData::Sdg -->
	<xsd:complexType name="SDG" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			&lt;sdg&gt; (Special Data Group) is a backdoor used to handle elements that has not yet been defined in a DTD. The &lt;sdg&gt; is a containder for one or several &lt;sd&gt; that defines new elements and carries the information. Special Data should only be used moderately since all elements should be defined in the dtd. Thereby should SDG be considered as a temporary sollution when elements are missing. If a &lt;sdgCaption&gt; element is created along with a &lt;shortName&gt; it is possible to reference the &lt;sdg&gt; structure via a &lt;xref&gt;.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-SDG";msr.id="type__SDG_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SDG"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:SDG"/>
	</xsd:complexType>
	<!-- attribute group for class MultilanguageData::MlData1 -->
	<xsd:attributeGroup name="ML-DATA-1">
		<xsd:annotation>
			<xsd:documentation>
			MultiLanguageParagraph

This is the content model of a multilinugal paragraph in a documentation.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-1"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="HELP-ENTRY" type="xsd:string"/>
		<xsd:attribute name="KEEP-WITH-PREVIOUS" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class MultilanguageData::MlData1 -->
	<xsd:complexType name="ML-DATA-1" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			MultiLanguageParagraph

This is the content model of a multilinugal paragraph in a documentation.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-1"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ML-DATA-MODEL-1"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:ML-DATA-1"/>
	</xsd:complexType>
	<!-- complex type for class MultilanguageData::MlData2 -->
	<xsd:complexType name="ML-DATA-2" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			MultiLanguageOverviewParagraph

This is the content of a multilingual paragraph in an overview item.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-2"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ML-DATA-MODEL-2"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class MultilanguageData::MlData3 -->
	<xsd:complexType name="ML-DATA-3" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			MultiLanguageUnitNames
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-3"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ML-DATA-MODEL-3"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- attribute group for class MultilanguageData::MlData3p -->
	<xsd:attributeGroup name="ML-DATA-3-P">
		<xsd:annotation>
			<xsd:documentation>
			MultiLanguageUnitNameVerbatim
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-3p"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="XMLSPACE" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class MultilanguageData::MlData3p -->
	<xsd:complexType name="ML-DATA-3-P" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			MultiLanguageUnitNameVerbatim
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-3p"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ML-DATA-MODEL-3"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:ML-DATA-3-P"/>
	</xsd:complexType>
	<!-- complex type for class MultilanguageData::MlData4 -->
	<xsd:complexType name="ML-DATA-4" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			MultilanguageLongName
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-4"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ML-DATA-MODEL-4"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- attribute group for class MultilanguageData::MlData5 -->
	<xsd:attributeGroup name="ML-DATA-5">
		<xsd:annotation>
			<xsd:documentation>
			MultiLanguageVerbatim
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-5"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="ALLOW-BREAK" type="xsd:string"/>
		<xsd:attribute name="FLOAT" type="xsd:string"/>
		<xsd:attribute name="HELP-ENTRY" type="xsd:string"/>
		<xsd:attribute name="KEEP-WITH-PREVIOUS" type="xsd:string"/>
		<xsd:attribute name="PGWIDE" type="xsd:string"/>
		<xsd:attribute name="XMLSPACE" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class MultilanguageData::MlData5 -->
	<xsd:complexType name="ML-DATA-5" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			MultiLanguageVerbatim
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-5"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ML-DATA-MODEL-5"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:ML-DATA-5"/>
	</xsd:complexType>
	<!-- complex type for class MultilanguageData::MlData10 -->
	<xsd:complexType name="ML-DATA-10" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			MultiLanguagePlainText
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__ml-data-10"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ML-DATA-MODEL-10"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class SingleLanguageData::SlData1 -->
	<xsd:complexType name="SL-DATA-1" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			SingleLanguageParagraph

This is the content model of a single language paragraph in a documentation.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__sl-data-1";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class SingleLanguageData::SlData10 -->
	<xsd:complexType name="SL-DATA-10" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			SingleLanguagePlainText
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__sl-data-10";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class SingleLanguageData::SlData2 -->
	<xsd:complexType name="SL-DATA-2" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			SingleLanguageOverviewParagraph

This is the model for a single language paragraph in an overview item.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__sl-data-2";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class SingleLanguageData::SlData3 -->
	<xsd:complexType name="SL-DATA-3" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			SingleLanguageUnitName

		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__sl-data-3";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- attribute group for class SingleLanguageData::SlData3p -->
	<xsd:attributeGroup name="SL-DATA-3-P">
		<xsd:annotation>
			<xsd:documentation>
			SingleLanguageUnitNameVerbatim
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__sl-data-3p";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="XMLSPACE" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class SingleLanguageData::SlData3p -->
	<xsd:complexType name="SL-DATA-3-P" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			SingleLanguageUnitNameVerbatim
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__sl-data-3p";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:SL-DATA-3-P"/>
	</xsd:complexType>
	<!-- complex type for class SingleLanguageData::SlData4 -->
	<xsd:complexType name="SL-DATA-4" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			SingleLanguageLongName
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__sl-data-4";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- attribute group for class SingleLanguageData::SlData5 -->
	<xsd:attributeGroup name="SL-DATA-5">
		<xsd:annotation>
			<xsd:documentation>
			SingleLanguageVerbatim
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__sl-data-5";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="ALLOW-BREAK" type="xsd:string"/>
		<xsd:attribute name="FLOAT" type="xsd:string"/>
		<xsd:attribute name="HELP-ENTRY" type="xsd:string"/>
		<xsd:attribute name="KEEP-WITH-PREVIOUS" type="xsd:string"/>
		<xsd:attribute name="PGWIDE" type="xsd:string"/>
		<xsd:attribute name="XMLSPACE" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class SingleLanguageData::SlData5 -->
	<xsd:complexType name="SL-DATA-5" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			SingleLanguageVerbatim
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__sl-data-5";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:SL-DATA-5"/>
	</xsd:complexType>
	<!-- element group for class ECUResourceTemplate::AssemblyHWConnection -->
	<xsd:group name="ASSEMBLY-HW-CONNECTION">
		<xsd:annotation>
			<xsd:documentation>
			An AssemblyHWConnection is established between at least two HWPorts provided by different HWElements. 
The AssemblyHWConnection can only be established between HWPorts on the same hierarchical level. To connect accross hierarchical levels use the DelegationHWConnection.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="HW-PORT-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="HW-PORT-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:HW-PORT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUResourceTemplate::AssemblyHWConnection -->
	<xsd:complexType name="ASSEMBLY-HW-CONNECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An AssemblyHWConnection is established between at least two HWPorts provided by different HWElements. 
The AssemblyHWConnection can only be established between HWPorts on the same hierarchical level. To connect accross hierarchical levels use the DelegationHWConnection.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-CONNECTION"/>
			<xsd:group ref="AR:ASSEMBLY-HW-CONNECTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUResourceTemplate::HWConnection -->
	<xsd:group name="HW-CONNECTION">
		<xsd:annotation>
			<xsd:documentation>
			Abstract class to specify the ability to connect HWPorts.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONNECTED-PINS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PIN-HW-CONNECTION" type="AR:PIN-HW-CONNECTION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class ECUResourceTemplate::PinHWConnection -->
	<xsd:group name="PIN-HW-CONNECTION">
		<xsd:annotation>
			<xsd:documentation>
			Is used to connect the HWPins of the HWPorts that are referenced by the HWConnection.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONNECTED-PIN-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="2">
						<xsd:element name="CONNECTED-PIN-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:HW-PIN--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUResourceTemplate::PinHWConnection -->
	<xsd:complexType name="PIN-HW-CONNECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Is used to connect the HWPins of the HWPorts that are referenced by the HWConnection.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PIN-HW-CONNECTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ECUResourceTemplate::HWPin -->
	<xsd:complexType name="HW-PIN" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A HWPin is an elementary electrical interface of the HWElement.
The HWPins of a HWPort can be clustered if there are some HWPins with the same behaviour.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="HW-PIN--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="HW-PIN"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUResourceTemplate::HWPort -->
	<xsd:group name="HW-PORT">
		<xsd:annotation>
			<xsd:documentation>
			The general element HW Port is necessary to connect HW Elements and contains common elements for all different kind of HW Ports.
HW Ports are required to be uniquely identifiable within the scope of a HW Element. This means to identify a specific HW Port it is necessary to prefix the HW Port name by the name of the HW Element (e.g.&quot;PU1/ADCPort3&quot;).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DIRECTION" type="AR:HW-PORT-DIRECTION-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The direction of a HW Port defines signal flow in the point of view of the HW Element the HW Port belongs to. The following attributes are allowed:
- In: The signal flow goes into the HW Element. The HW Element is the target for a signal.
- Out: The signal flow goes from the HW Element away. The HW Element is the source of a signal.
- InOut: Both, incoming and outgoing signal flows are allowed.

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PINS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="HW-PIN" type="AR:HW-PIN"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUResourceTemplate::HWPort -->
	<xsd:complexType name="HW-PORT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The general element HW Port is necessary to connect HW Elements and contains common elements for all different kind of HW Ports.
HW Ports are required to be uniquely identifiable within the scope of a HW Element. This means to identify a specific HW Port it is necessary to prefix the HW Port name by the name of the HW Element (e.g.&quot;PU1/ADCPort3&quot;).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-PORT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="HW-PORT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMMUNICATION-HW-PORT"/>
			<xsd:enumeration value="ECU-COMMUNICATION-PORT"/>
			<xsd:enumeration value="HW-PORT"/>
			<xsd:enumeration value="INTERRUPT-CONSUME-HW-PORT"/>
			<xsd:enumeration value="INTERRUPT-PRODUCE-HW-PORT"/>
			<xsd:enumeration value="MEMORY-MAPPED-HW-PORT"/>
			<xsd:enumeration value="PERIPHERAL-HW-PORT"/>
			<xsd:enumeration value="POWER-DRIVER-HW-PORT"/>
			<xsd:enumeration value="POWER-SUPPLY-HW-PORT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="HW-PORT-DIRECTION-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="IN"/>
			<xsd:enumeration value="OUT"/>
			<xsd:enumeration value="INOUT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUResourceTemplate::DelegationHWConnection -->
	<xsd:group name="DELEGATION-HW-CONNECTION">
		<xsd:annotation>
			<xsd:documentation>
			Is used to connect HWPorts of a HWContainer with HWPorts of the contained HWElements.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="INNER-PORT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:HW-PORT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OUTER-PORT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:HW-PORT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUResourceTemplate::DelegationHWConnection -->
	<xsd:complexType name="DELEGATION-HW-CONNECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Is used to connect HWPorts of a HWContainer with HWPorts of the contained HWElements.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-CONNECTION"/>
			<xsd:group ref="AR:DELEGATION-HW-CONNECTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUResourceTemplate::ECU -->
	<xsd:group name="ECU">
		<xsd:annotation>
			<xsd:documentation>
			The ECU provides information about an ECU and its internal hardware elements. The described hardware elements are related to some extent to basic software configuration and the AUTOSAR generation process.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ECU-ABSTRACTION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUResourceTemplate::ECU -->
	<xsd:complexType name="ECU" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The ECU provides information about an ECU and its internal hardware elements. The described hardware elements are related to some extent to basic software configuration and the AUTOSAR generation process.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:HW-ELEMENT-CONTAINER"/>
			<xsd:group ref="AR:ECU"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ECU--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ECU"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUResourceTemplate::HWElementContainer -->
	<xsd:group name="HW-ELEMENT-CONTAINER">
		<xsd:annotation>
			<xsd:documentation>
			Abstract class to enable the collection of HW Elements.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONNECTIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ASSEMBLY-HW-CONNECTION" type="AR:ASSEMBLY-HW-CONNECTION"/>
						<xsd:element name="DELEGATION-HW-CONNECTION" type="AR:DELEGATION-HW-CONNECTION"/>
						<xsd:element name="MEMORY-MAPPED-ASSEMBLY-HW-CONNECTION" type="AR:MEMORY-MAPPED-ASSEMBLY-HW-CONNECTION"/>
						<xsd:element name="MEMORY-MAPPED-DELEGATION-HW-CONNECTION" type="AR:MEMORY-MAPPED-DELEGATION-HW-CONNECTION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CONTAINED-ELEMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ADC" type="AR:ADC"/>
						<xsd:element name="ACTUATOR-HW" type="AR:ACTUATOR-HW"/>
						<xsd:element name="CCU" type="AR:CCU"/>
						<xsd:element name="CLOCK" type="AR:CLOCK"/>
						<xsd:element name="COMMUNICATION-PERIPHERAL" type="AR:COMMUNICATION-PERIPHERAL"/>
						<xsd:element name="COMMUNICATION-TRANSCEIVER" type="AR:COMMUNICATION-TRANSCEIVER"/>
						<xsd:element name="DAC" type="AR:DAC"/>
						<xsd:element name="DIGITAL-IO" type="AR:DIGITAL-IO"/>
						<xsd:element name="DISCRETE-ECU-ELECTRONICS" type="AR:DISCRETE-ECU-ELECTRONICS"/>
						<xsd:element name="DISPLAY-HW" type="AR:DISPLAY-HW"/>
						<xsd:element name="ECU" type="AR:ECU"/>
						<xsd:element name="HW-CONTAINER" type="AR:HW-CONTAINER"/>
						<xsd:element name="OSCILLATOR" type="AR:OSCILLATOR"/>
						<xsd:element name="PWD" type="AR:PWD"/>
						<xsd:element name="PWM" type="AR:PWM"/>
						<xsd:element name="PERIPHERAL" type="AR:PERIPHERAL"/>
						<xsd:element name="POWER-DRIVER-HW-ELEMENT" type="AR:POWER-DRIVER-HW-ELEMENT"/>
						<xsd:element name="POWER-SUPPLY-HW-ELEMENT" type="AR:POWER-SUPPLY-HW-ELEMENT"/>
						<xsd:element name="PROCESSING-UNIT" type="AR:PROCESSING-UNIT"/>
						<xsd:element name="PROVIDED-MEMORY-SEGMENT" type="AR:PROVIDED-MEMORY-SEGMENT"/>
						<xsd:element name="PROVIDED-NV-MEMORY-SEGMENT" type="AR:PROVIDED-NV-MEMORY-SEGMENT"/>
						<xsd:element name="SENSOR-HW" type="AR:SENSOR-HW"/>
						<xsd:element name="TIMER" type="AR:TIMER"/>
						<xsd:element name="WATCH-DOG" type="AR:WATCH-DOG"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class ECUResourceTemplate::HWElement -->
	<xsd:group name="HW-ELEMENT">
		<xsd:annotation>
			<xsd:documentation>
			The General HW Element specifies definitions valid for all specific HW Elements.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="HW-ELEMENT-TEMPERATURE" type="AR:TEMPERATURE" minOccurs="0"/>
			<xsd:element name="PORTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMMUNICATION-HW-PORT" type="AR:COMMUNICATION-HW-PORT"/>
						<xsd:element name="ECU-COMMUNICATION-PORT" type="AR:ECU-COMMUNICATION-PORT"/>
						<xsd:element name="HW-PORT" type="AR:HW-PORT"/>
						<xsd:element name="INTERRUPT-CONSUME-HW-PORT" type="AR:INTERRUPT-CONSUME-HW-PORT"/>
						<xsd:element name="INTERRUPT-PRODUCE-HW-PORT" type="AR:INTERRUPT-PRODUCE-HW-PORT"/>
						<xsd:element name="MEMORY-MAPPED-HW-PORT" type="AR:MEMORY-MAPPED-HW-PORT"/>
						<xsd:element name="PERIPHERAL-HW-PORT" type="AR:PERIPHERAL-HW-PORT"/>
						<xsd:element name="POWER-DRIVER-HW-PORT" type="AR:POWER-DRIVER-HW-PORT"/>
						<xsd:element name="POWER-SUPPLY-HW-PORT" type="AR:POWER-SUPPLY-HW-PORT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIGNAL-TRANSFORMATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SIGNAL-TRANSFORMATION" type="AR:SIGNAL-TRANSFORMATION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="STANDBY-CURRENT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The Standby Current is the current in state OFF. For HW Elements the Standby Current consists of the current needed by the logic to stay in the state OFF and the leakage current of the HW Element. For big HW Elements the leakage current can be up to several 100 microA.
Standby Current is used to determine which elements are necessary to be switch off, when the car itself is in a standby mode. This can be done automatically or by the user.
The value for the Standby Current can be entered for each HW Element and HW Container respectively. The user has to take care about these values and decides about the entries necessary for the calculation of the complete standby current. On the other side the sum for all HW Elements grouped in a HW Container may have a bigger value than the value for the HW Container itself. In this case the values for the HW Elements represent the worst case for each HW Element. 
Unit: Ampere (A)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SUPPORTS-SAFETY" type="AR:SUPPORTS-SAFETY" minOccurs="0"/>
			<xsd:element name="SUPPORTS-SECURITY" type="AR:SUPPORTS-SECURITY" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class ECUResourceTemplate::SignalTransformation -->
	<xsd:group name="SIGNAL-TRANSFORMATION">
		<xsd:annotation>
			<xsd:documentation>
			The Signal Transformation defines the conversion of the signal attached to a HW Port (direction In) and a signal attached to a HW Port (direction Out).

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="INPUT-HW-PORT-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="INPUT-HW-PORT-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:HW-PORT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OUTPUT-HW-PORT-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="OUTPUT-HW-PORT-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:HW-PORT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUResourceTemplate::SignalTransformation -->
	<xsd:complexType name="SIGNAL-TRANSFORMATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The Signal Transformation defines the conversion of the signal attached to a HW Port (direction In) and a signal attached to a HW Port (direction Out).

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SIGNAL-TRANSFORMATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ECUResourceTemplate::HWContainer -->
	<xsd:complexType name="HW-CONTAINER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A HW Container is a group of HW Elements on the same hierarchical level and is an abstraction of composite HW Elements. The HW Container is a specialisation of a HW Element and therefore the HW Container has all elements of a HW Element.
The values of elements of the HW Elements grouped in a HW Container may differ from the values of the elements of the HW Container.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:HW-ELEMENT-CONTAINER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class BasicElements::BootTime -->
	<xsd:group name="BOOT-TIME">
		<xsd:annotation>
			<xsd:documentation>
			Time information for ECU and PU startup.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COLD-START-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Time it takes to come from a completely powered down state to the HWInit state in seconds.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESET-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Time it takes from the reset initiation to the HWInit state in seconds.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BasicElements::BootTime -->
	<xsd:complexType name="BOOT-TIME" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Time information for ECU and PU startup.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:BOOT-TIME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class BasicElements::ElectricalRange -->
	<xsd:group name="ELECTRICAL-RANGE">
		<xsd:annotation>
			<xsd:documentation>
			Specifies electrical ranges for different applications within the ECU Resource Template.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MAX-CURRENT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum Current
Unit: A
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-VOLTAGE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum voltage
Unit: V
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-CURRENT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Minimum Current
Unit: A
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-VOLTAGE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Minimum voltage
Unit: V
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TYPICAL-CURRENT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Typical Current
Unit: A
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TYPICAL-VOLTAGE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Typical voltage
Unit: V
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BasicElements::ElectricalRange -->
	<xsd:complexType name="ELECTRICAL-RANGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specifies electrical ranges for different applications within the ECU Resource Template.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ELECTRICAL-RANGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class BasicElements::ErrorDetectionCorrection -->
	<xsd:group name="ERROR-DETECTION-CORRECTION">
		<xsd:annotation>
			<xsd:documentation>
			Provides information on what extra bits are used for error detection and correction.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CORRECTED-BITS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			How many error bits can be corrected.
Unit: Bit
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DETECTED-BITS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			How many bit errors can be reconginsed.
Unit: Bit
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="EXTRA-BITS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			How many extra bits are used for ensuring error detection and correction.
Unit: Bit
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BasicElements::ErrorDetectionCorrection -->
	<xsd:complexType name="ERROR-DETECTION-CORRECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Provides information on what extra bits are used for error detection and correction.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ERROR-DETECTION-CORRECTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class BasicElements::FrequencyRange -->
	<xsd:group name="FREQUENCY-RANGE">
		<xsd:annotation>
			<xsd:documentation>
			Class describing minimum, maximum and typical frequencies.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MAX-FREQUENCY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum frequency.
Unit: Herz
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-FREQUENCY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Minimum frequency.
Unit: Herz
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TYPICAL-FREQUENCY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Typical frequency.
Unit: Herz
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BasicElements::FrequencyRange -->
	<xsd:complexType name="FREQUENCY-RANGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Class describing minimum, maximum and typical frequencies.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:FREQUENCY-RANGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class BasicElements::MemoryAccess -->
	<xsd:group name="MEMORY-ACCESS">
		<xsd:annotation>
			<xsd:documentation>
			Describes the different possible kinds of access to the memory and the time these access takes.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACCESS-TYPE" type="AR:MEMORY-ACCESS-ACCESS-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The element access type describes the different possible kinds of access to the memory. 
- Read Access: Read Access is available to all memory by default. The data is copied from the memory to another location. 
- Write Access: Possible only with RAM devices. Data is copied to the memory. 
- Erase Access: Data stored in specific memory areas is erased and the memory is transferred to a defined initial-state. The erase access is a complex process. The erase access is in many cases prerequisite of a program access. Used on EPROM, EEPROM and Flash. 
- Program Access: The transfer of data to PROM, EPROM, EEPROM or Flash. In the difference to write access the program access takes more time and is a more complex process to transfer the data. Data is copied to the memory. 
- Random Access: Data access is not sequenced in memory. Time restrictions are valid in order to address the appropriate memory location and getting the right to access this location with single access. The access time of single data is the important characteristic. 
- Sequenced Access: The wanted data can only be achieved by reading a defined sequence of data in advance. Typical examples are tapes, certain EEPROM or hardware implemented stacks. 
- Burst-Mode: A group of data is accessed. The data is stored in continuous addresses and is copied in continuous set of data transfer without an interruption. Access time for the overall data transfer is minimised. For the set-up of a burst mode time restrictions are valid in order to address the appropriate memory location and getting the right to access this location in burst-mode. Set-up time for burst-mode, transfer time of first byte, transfer time of last byte, transfer time for intermediate bytes of a burst and the number of bytes per burst-access are the characteristics of burst-mode access. 
Burst-mode is used to transfer great amount of data e.g. from a memory with slow access times to a memory with fast access time. 
Note: The access is denied during erasure and programming of Flash and EEPROM as some technologies do not allow a simultaneous read access to that specific memory area.
Also during the simultaneous access of different subscribers on the same memory, array or byte the access is either denied or at least delayed. For example if the CPU and the DMA write to the same memory block.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TIME" type="AR:TIME-RANGE" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BasicElements::MemoryAccess -->
	<xsd:complexType name="MEMORY-ACCESS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Describes the different possible kinds of access to the memory and the time these access takes.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MEMORY-ACCESS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="MEMORY-ACCESS-ACCESS-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="READ"/>
			<xsd:enumeration value="WRITE"/>
			<xsd:enumeration value="ERASE"/>
			<xsd:enumeration value="PROGRAMM"/>
			<xsd:enumeration value="RANDOM"/>
			<xsd:enumeration value="SEQUENCE"/>
			<xsd:enumeration value="BURST"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class BasicElements::TimeRange -->
	<xsd:group name="TIME-RANGE">
		<xsd:sequence>
			<xsd:element name="MAX" type="xsd:double" minOccurs="0"/>
			<xsd:element name="MIN" type="xsd:double" minOccurs="0"/>
			<xsd:element name="TYPICAL" type="xsd:double" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BasicElements::TimeRange -->
	<xsd:complexType name="TIME-RANGE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:TIME-RANGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class BasicElements::SupportsSafety -->
	<xsd:complexType name="SUPPORTS-SAFETY" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			In the current version of the ECU Resource Template the element SupportsSafety is optional. A HW Element uses this element if it provides a safety mechanism, otherwise this element is missing in the description of the HW Element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class BasicElements::SupportsSecurity -->
	<xsd:complexType name="SUPPORTS-SECURITY" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The ECU Resource Template provides the element SupportsSecurity storing the information about the supported security mechanism.
In the current version of the ECU Resource Template the element SupportsSecurity is optional. A HW Element uses this element if it provides a security mechanism otherwise this element is missing in the description of the HW Element.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class BasicElements::Temperature -->
	<xsd:group name="TEMPERATURE">
		<xsd:annotation>
			<xsd:documentation>
			General element to describe temperature ranges and need for cooling/heating.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="NEEDS-COOLING" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			These attributes describe that there is an active cooling system required for this HW Element.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NEEDS-HEATING" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			These attributes describe that there is an active heating system required for this HW Element.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OPERATION-MAX" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			It describes the temperature range (max) in which the HW Element can be operated.
Unit: Kelvin (K)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OPERATION-MIN" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			It describes the temperature range (min) in which the HW Element can be operated.
Unit: Kelvin (K)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OPERATION-TYPICAL" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			It describes the temperature range (typical) in which the HW Element can be operated.
Unit: Kelvin (K)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="STORAGE-MAX" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The storage temperature defines maximum temperature the device is allowed to be stored. The HW Element is not in an operational state.
Unit: Kelvin (K)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="STORAGE-MIN" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The storage temperature defines minimum temperature the device is allowed to be stored. The HW Element is not in an operational state.
Unit: Kelvin (K)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BasicElements::Temperature -->
	<xsd:complexType name="TEMPERATURE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			General element to describe temperature ranges and need for cooling/heating.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:TEMPERATURE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::Buffer -->
	<xsd:group name="BUFFER">
		<xsd:annotation>
			<xsd:documentation>
			Description of a  buffer. It is used to describe input and output buffers.
Buffers can also be configurable direction.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="NUMBER" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The amount of buffers with the attributes size and type.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SIZE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The size of the Buffer.
Unit: Byte
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TYPE" type="AR:BUFFER-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Either input, output or configurable buffer.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::Buffer -->
	<xsd:complexType name="BUFFER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Description of a  buffer. It is used to describe input and output buffers.
Buffers can also be configurable direction.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:BUFFER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="BUFFER-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="INPUT"/>
			<xsd:enumeration value="OUTPUT"/>
			<xsd:enumeration value="INOUT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Peripherals::CCU -->
	<xsd:group name="CCU">
		<xsd:annotation>
			<xsd:documentation>
			The CCU is a special kind of a timer, which has the capability of counting and comparing external signals. The timer is equipped with some extra registers and comparators in order to measure time or frequency.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MODE" type="AR:CCU-MODE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			A Capture and Compare peripheral can be configured to operate either in capture or compare mode.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::CCU -->
	<xsd:complexType name="CCU" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The CCU is a special kind of a timer, which has the capability of counting and comparing external signals. The timer is equipped with some extra registers and comparators in order to measure time or frequency.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
			<xsd:group ref="AR:GENERAL-PURPOSE-TIMER"/>
			<xsd:group ref="AR:CCU"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::GeneralPurposeTimer -->
	<xsd:group name="GENERAL-PURPOSE-TIMER">
		<xsd:annotation>
			<xsd:documentation>
			Common attributes shared by all timer peripherals
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CLOCK-SOURCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OSCILLATOR--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PHASE-DETECTION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Some timers have the possibility to detect signals from a quadrature rotating switch. There are two outputs signal from such a switch; the signals are 90 degrees phase shifted from each other. The rotation of the switch can then automatically be detected by a special function in a timer.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESOLUTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			For a timer the resolution defines the data width of the counter.
Unit: Bits
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="THRESHOLD-VALUE" type="xsd:integer" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			The threshold is the definition of a counter value. When the counter has reached this value some action is performed, e.g. an interrupt can be generated.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class Peripherals::Peripheral -->
	<xsd:group name="PERIPHERAL">
		<xsd:annotation>
			<xsd:documentation>
			General Element for all peripherals.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CAN-BE-DISABLED" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines if the peripheral can be logically enabled or disabled.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::Peripheral -->
	<xsd:complexType name="PERIPHERAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			General Element for all peripherals.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::CommunicationFilter -->
	<xsd:group name="COMMUNICATION-FILTER">
		<xsd:annotation>
			<xsd:documentation>
			Describes the amount and the size of the communication filters. These can be used as acceptance or rejection filters.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="FILTER-COUNT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			How many acceptance filters are availabe.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="FILTER-WIDTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Which bit-size do the filters have.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WILD-CARDS" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Is it possible to provide wildcard identifires allowing to specify ranges for filtering.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::CommunicationFilter -->
	<xsd:complexType name="COMMUNICATION-FILTER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Describes the amount and the size of the communication filters. These can be used as acceptance or rejection filters.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:COMMUNICATION-FILTER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="CCU-MODE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CAPTURE"/>
			<xsd:enumeration value="COMPARE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Peripherals::CommunicationHWPort -->
	<xsd:group name="COMMUNICATION-HW-PORT">
		<xsd:sequence>
			<xsd:element name="PHYSICAL-LAYER" type="AR:COMMUNICATION-PHYSICAL-MEDIUM" minOccurs="0"/>
			<xsd:element name="SPEED" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0">
						<xsd:element name="COMMUNICATION-SPEED-FIXED" type="AR:COMMUNICATION-SPEED-FIXED"/>
						<xsd:element name="COMMUNICATION-SPEED-LIST" type="AR:COMMUNICATION-SPEED-LIST"/>
						<xsd:element name="COMMUNICATION-SPEED-RANGE" type="AR:COMMUNICATION-SPEED-RANGE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::CommunicationHWPort -->
	<xsd:complexType name="COMMUNICATION-HW-PORT" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-PORT"/>
			<xsd:group ref="AR:PERIPHERAL-HW-PORT"/>
			<xsd:group ref="AR:COMMUNICATION-HW-PORT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::PeripheralHWPort -->
	<xsd:group name="PERIPHERAL-HW-PORT">
		<xsd:annotation>
			<xsd:documentation>
			This port is directed from the peripheral to the ecu electronics and communication.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BUFFERS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="BUFFER" type="AR:BUFFER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="INVERSION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			An input or output can sometimes be programmed to invert the level of a signal.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="POWER-ON-CAPABILITY" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The peripheral device has the feature to issue a Power On event to the ECU.
Example: Some CAN bus transceivers have a dedicated low power voltage regulator and a feature, which allows to turn on the main voltage regulator of the ECU by detecting a bus activity.
Example: A wired-or connection of a termination KL30 and KL15 can fulfil this requirement.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP-CAPABILITY" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The peripheral device has the feature to issue a wake-up event to the processing unit.
Example: HW Port with Key-Wake-Up on a PU is still active while the PU is in stop mode and only partially supplied with power. The Key-Wake-Up reacts on any changes at the input of the HW Port with the activation of the power supply, the activation of the clock system and later the resuming of the software, which has to process the input of the HW Port.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::PeripheralHWPort -->
	<xsd:complexType name="PERIPHERAL-HW-PORT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This port is directed from the peripheral to the ecu electronics and communication.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-PORT"/>
			<xsd:group ref="AR:PERIPHERAL-HW-PORT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::CommunicationSpeed -->
	<xsd:group name="COMMUNICATION-SPEED">
		<xsd:annotation>
			<xsd:documentation>
			Abstract element to describe communication speed. This can be either a fixed value, a range or a list of allowed communication speed.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="TOLERANCE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The element defines the tolerance allowed for the interface. (E.g. K-Line or LIN +/- 2 % at 9.6 Kbd)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class Peripherals::CommunicationPhysicalMedium -->
	<xsd:group name="COMMUNICATION-PHYSICAL-MEDIUM">
		<xsd:annotation>
			<xsd:documentation>
			Describes the physical medium the bus is working on. In most cases it is not relevant for the SW to know about it, only for compatibility checking.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PHYSICAL-MEDIUM-DATA-LINES" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies how many data lines (ground not included) are used for the physical layer. Some bus systems can be implemented with e.g. 1, 2 or 4 data lines.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PHYSICAL-MEDIUM-STANDARD" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The element protocol name defines the exact standardised protocol name.
Examples are:
- ISO 11519 for low-speed CAN
- IEEE 802.11g for W-LAN (54 Mbit/s at 2,5 GHz)
- IEEE-1394a for Firewire-400

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PHYSICAL-MEDIUM-TYPE" type="AR:COMMUNICATION-PHYSICAL-MEDIUM-PHYSICAL-MEDIUM-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describes the actual medium used for transmission. Can be either electrical, optical or wireless.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::CommunicationPhysicalMedium -->
	<xsd:complexType name="COMMUNICATION-PHYSICAL-MEDIUM" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Describes the physical medium the bus is working on. In most cases it is not relevant for the SW to know about it, only for compatibility checking.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:COMMUNICATION-PHYSICAL-MEDIUM"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="COMMUNICATION-PHYSICAL-MEDIUM-PHYSICAL-MEDIUM-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ELECTRICAL"/>
			<xsd:enumeration value="OPTICAL"/>
			<xsd:enumeration value="WIRELESS"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Peripherals::CommunicationPeripheral -->
	<xsd:group name="COMMUNICATION-PERIPHERAL">
		<xsd:annotation>
			<xsd:documentation>
			Peripheral representing communication devices.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACCEPTANCE-FILTER" type="AR:COMMUNICATION-FILTER" minOccurs="0"/>
			<xsd:element name="ARCHITECTURE" type="AR:COMMUNICATION-PERIPHERAL-ARCHITECTURE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Distinguish between different implementations.
- Master: Defines the position within the ECU, as the main controlling unit. The master defines the schedules and controls the telegram traffic.
- Slave: Reacts only on request from the master
- Multi Master: The PU has to share the external Interface with other PU. No specific master is defined by hardware.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CLOCK-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CLOCK--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ERROR-DETECTION" type="AR:ERROR-DETECTION-CORRECTION" minOccurs="0"/>
			<xsd:element name="HW-PORTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMMUNICATION-HW-PORT" type="AR:COMMUNICATION-HW-PORT"/>
						<xsd:element name="ECU-COMMUNICATION-PORT" type="AR:ECU-COMMUNICATION-PORT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MONITOR" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The Element Monitor specifies if the device supports listen only. In this mode the device is passive on the bus and no acknowledgement or other responds are transmitted.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PROTOCOLS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMMUNICATION-PROTOCOL" type="AR:COMMUNICATION-PROTOCOL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="REJECTION-FILTER" type="AR:COMMUNICATION-FILTER" minOccurs="0"/>
			<xsd:element name="TIMESTAMP-AVAILABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Is a timestamp for received frames available.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::CommunicationPeripheral -->
	<xsd:complexType name="COMMUNICATION-PERIPHERAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Peripheral representing communication devices.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
			<xsd:group ref="AR:COMMUNICATION-PERIPHERAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMMUNICATION-PERIPHERAL-ARCHITECTURE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MASTER"/>
			<xsd:enumeration value="SLAVE"/>
			<xsd:enumeration value="MULTI-MASTER"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Peripherals::CommunicationProtocol -->
	<xsd:group name="COMMUNICATION-PROTOCOL">
		<xsd:annotation>
			<xsd:documentation>
			The name and version of the communication protocol.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VERSION" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			This is the version number of the implementation of the protocol layer, e.g. 
- 2.0a, 2.0b  for CAN.
- 1.3, 2.0 for LIN.
- 2.0   for USB.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::CommunicationProtocol -->
	<xsd:complexType name="COMMUNICATION-PROTOCOL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The name and version of the communication protocol.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMMUNICATION-PROTOCOL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::CommunicationSpeedFixed -->
	<xsd:group name="COMMUNICATION-SPEED-FIXED">
		<xsd:annotation>
			<xsd:documentation>
			Fixed value for the communication speed.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="FIX-SPEED" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Unit: bits per second
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::CommunicationSpeedFixed -->
	<xsd:complexType name="COMMUNICATION-SPEED-FIXED" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Fixed value for the communication speed.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:COMMUNICATION-SPEED"/>
			<xsd:group ref="AR:COMMUNICATION-SPEED-FIXED"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::CommunicationSpeedList -->
	<xsd:group name="COMMUNICATION-SPEED-LIST">
		<xsd:annotation>
			<xsd:documentation>
			List of possible communication speed.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SPEED" type="xsd:integer" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			Unit: bits per second
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::CommunicationSpeedList -->
	<xsd:complexType name="COMMUNICATION-SPEED-LIST" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			List of possible communication speed.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:COMMUNICATION-SPEED"/>
			<xsd:group ref="AR:COMMUNICATION-SPEED-LIST"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::CommunicationSpeedRange -->
	<xsd:group name="COMMUNICATION-SPEED-RANGE">
		<xsd:annotation>
			<xsd:documentation>
			Range of communication speed.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MAX-SPEED" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Unit: bits per second
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-SPEED" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Unit: bits per second
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::CommunicationSpeedRange -->
	<xsd:complexType name="COMMUNICATION-SPEED-RANGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Range of communication speed.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:COMMUNICATION-SPEED"/>
			<xsd:group ref="AR:COMMUNICATION-SPEED-RANGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::Timer -->
	<xsd:group name="TIMER">
		<xsd:annotation>
			<xsd:documentation>
			The simplest form is an array of directly coupled D-flip flops, which build up a shift register, with separate output from each stage, thus forming a time-register. A clock signal at the input increments the value of the register. Some cases uses some logic in combination of the shift register in order to form a special adopted representation of the information or to fulfil special requirements.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CAN-BE-RE-INIT" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines if the peripheral can automatically be reset during operation.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="COUNT-DIRECTION" type="AR:TIMER-COUNT-DIRECTION-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The direction defines if the counter of a timer counts up, down or if it can be selected.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MODE" type="AR:TIMER-MODE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			single: The timer is counted from a defined start value to a defined end value and then stopped. 
continuous: The timer is counted from a defined start value to a defined end value and then restarted with the start value.
free: The timer is counted always to the available maximum value of the timer structure, then a wrap around occurs and the timer starts again from the HW defined startpoint; e.g. a 16 bit Timer counts from 0(hex)....0FFFF(hex), then after the overflow again from 0(hex)....0FFFF(hex).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::Timer -->
	<xsd:complexType name="TIMER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The simplest form is an array of directly coupled D-flip flops, which build up a shift register, with separate output from each stage, thus forming a time-register. A clock signal at the input increments the value of the register. Some cases uses some logic in combination of the shift register in order to form a special adopted representation of the information or to fulfil special requirements.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
			<xsd:group ref="AR:GENERAL-PURPOSE-TIMER"/>
			<xsd:group ref="AR:TIMER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="TIMER-COUNT-DIRECTION-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="UP"/>
			<xsd:enumeration value="DOWN"/>
			<xsd:enumeration value="SELECTABLE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="TIMER-MODE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CONTINUOUS"/>
			<xsd:enumeration value="SINGLE"/>
			<xsd:enumeration value="FREE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Peripherals::WatchDog -->
	<xsd:group name="WATCH-DOG">
		<xsd:annotation>
			<xsd:documentation>
			A form of interval timer, which is used to detect a possible malfunction of the processing unit. The timer is started as a countdown and has to be triggered within a specific time. Either the trigger only has to occur before the count-down runs out, or the trigger has to occur within a specific window before the timeout, therefore a trigger too early will also set off the watchdog. If the trigger is not correctly performed the watchdog will set off and will initiate an interrupt or perform a reset of the whole processing unit or ECU.
The watchdog can be implemented in software or hardware and if the implementation is in hardware it can be integrated into the processing unit or connected externally.
Depending on the complexity of the watchdog the interfacing is either a serial communication or some discrete I/O lines. Also the trigger itself can be just some digital peak or can be some calculated request-response mechanism. The actual handling of the watchdog has to be covered by some specific driver software.
The watchdog will use at least an interrupt of the processing unit and also some peripheral connections for the control and set-up.
To enable different operating modes of the processing unit and the ECU it is important to specify if the watchdog can be disabled (e.g. during flash programming).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CLOCK-SOURCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OSCILLATOR--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODE" type="AR:WATCH-DOG-MODE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			A Watchdog can be running in different modes. In normal mode must the watchdog be kicked within a certain maximum time. In the windowed mode there is also a lower limit of the time when the watchdog has to be kicked. In debug mode is the watchdog disabled. Sometimes it&apos;s also required that the watchdog can be disabled and enabled during software download. To ensure that this mode is not entered in normal operation there is often some kind of security procedure to enter the mode.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="THRESHOLD-VALUE" type="xsd:integer" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			The threshold is the definition of a counter value. When the counter has reached this value some action is performed, e.g. an interrupt can be generated.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::WatchDog -->
	<xsd:complexType name="WATCH-DOG" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A form of interval timer, which is used to detect a possible malfunction of the processing unit. The timer is started as a countdown and has to be triggered within a specific time. Either the trigger only has to occur before the count-down runs out, or the trigger has to occur within a specific window before the timeout, therefore a trigger too early will also set off the watchdog. If the trigger is not correctly performed the watchdog will set off and will initiate an interrupt or perform a reset of the whole processing unit or ECU.
The watchdog can be implemented in software or hardware and if the implementation is in hardware it can be integrated into the processing unit or connected externally.
Depending on the complexity of the watchdog the interfacing is either a serial communication or some discrete I/O lines. Also the trigger itself can be just some digital peak or can be some calculated request-response mechanism. The actual handling of the watchdog has to be covered by some specific driver software.
The watchdog will use at least an interrupt of the processing unit and also some peripheral connections for the control and set-up.
To enable different operating modes of the processing unit and the ECU it is important to specify if the watchdog can be disabled (e.g. during flash programming).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
			<xsd:group ref="AR:WATCH-DOG"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="WATCH-DOG-MODE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="NORMAL"/>
			<xsd:enumeration value="WINDOWED"/>
			<xsd:enumeration value="DEBUG"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Peripherals::ADC -->
	<xsd:group name="ADC">
		<xsd:annotation>
			<xsd:documentation>
			An ADC converts an analogue signal at an input pin to a digital value. The analogue signal are quantified to a maximum number of different levels defined by the resolution of the ADC. The Accuracy of the ADC is important for the overall functionality.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BEHAVIOUR-AT-LIMIT" type="AR:ADC-BEHAVIOUR-AT-LIMIT-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the action that is going to be performed when a limit is reached.
- Clipping: Logical value is limited to minimal or maximal range of the value range. E.g. The max. resolution of an ADC is at 5V represented 0xFF; in case off clipping a voltage of 6V is also represented as 0xFF;
- Undefined: Exceeding the resolution results in an undefined representation of the logical value. 
- Default: Exceeding the resolution results in a predefined default value. The default value might be a value, which report the status to the application e.g. as an error condition. 
- Other: A predefined function occur in order to prevent a undefined logical value. A typical application is a &quot;Soft-Clipping&quot; in a logarithmic form at the limit of the resolutions in audio applications.  The according methods have to be specified in the signal description.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::ADC -->
	<xsd:complexType name="ADC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An ADC converts an analogue signal at an input pin to a digital value. The analogue signal are quantified to a maximum number of different levels defined by the resolution of the ADC. The Accuracy of the ADC is important for the overall functionality.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
			<xsd:group ref="AR:ANALOGUE-IO"/>
			<xsd:group ref="AR:ADC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::AnalogueIO -->
	<xsd:group name="ANALOGUE-IO">
		<xsd:annotation>
			<xsd:documentation>
			These are the common attributes for both, the ADC and the DAC.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACCURACY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			There is a number of different conversion error in an ADC or DAC like non-linearity and absolute error. The accuracy is defined as the total error and it can be expressed as a deviation from its nominal value by e.g. 0.5, 1.0, 1.5 or 2.0 LSB.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CONVERSION-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			ADC: The conversion time is the definition how long it takes for an ADC to convert an analogue signal to a digital value.
DAC: The conversion time is the definition how long it takes for a DAC to convert a digital value to an analogue signal.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="EXTERNAL-REFERENCE-VOLTAGE" type="AR:ELECTRICAL-RANGE" minOccurs="0"/>
			<xsd:element name="MODE" type="AR:ANALOGUE-IO-MODE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			An ADC or DAC can operate in continuous, single  or sequential mode. In the continuous mode the conversion is automatically repeated after a completion. In single shot only one conversion is performed. For the sequential mode can a predefined number of different analogue channels be converted.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MULTIPLEXED-M" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the design of a simple multiplexer used by an ADC. Example A 2:8-multiplexer has 2 input channels and 8 registers. M is the second value.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MULTIPLEXED-N" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the design of a simple multiplexer used by an ADC. Example A 2:8-multiplexer has 2 input channels and 8 registers. N is the first value.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESOLUTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			For an Analogue to Digital Converter the resolution defines the number of different voltage levels, which are converted to a digital value. For example, an ADC with 10-bits resolution have the ability to convert an analogue value into 1024 different digital  values.
Unit: Bits
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WIDTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of Bits used to store the digital value.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="ANALOGUE-IO-MODE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CONTINUOUS"/>
			<xsd:enumeration value="SINGLE"/>
			<xsd:enumeration value="SEQUENTIAL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="ADC-BEHAVIOUR-AT-LIMIT-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CLIPPING"/>
			<xsd:enumeration value="DEFAULT"/>
			<xsd:enumeration value="UNDEFINED"/>
			<xsd:enumeration value="OTHER"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Peripherals::DAC -->
	<xsd:complexType name="DAC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The processing unit writes a digital value to a register of the DAC and the value is converted to an analogue value at a given pin.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
			<xsd:group ref="AR:ANALOGUE-IO"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::DigitalIO -->
	<xsd:group name="DIGITAL-IO">
		<xsd:annotation>
			<xsd:documentation>
			Digital Input/Output peripherals provide the capability to send/receive data in a digital manner. Each digital input has an electrical range. When the voltage is less than a specified level, the input is represents logical low &apos;0&apos;. On the opposite when the voltage is higher than a specified value the input represents logical high &apos;1&apos;. A digital I/O can usually be programmed to be either an input or output. It can also be programmed to logically invert the input or output. The maximum frequency of a digital input or output is related to how fast the PU can read or write to the digital I/O register. It&apos;s very common for a digital I/O to have different functionality. One example is when a timer has an external clock signal associated with a digital I/O. In this case the maximum frequency is defined by the performance of the timer counter and can be found in the electrical characteristic of the peripheral datasheet.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="EDGE-DETECTION" type="AR:DIGITAL-IO-EDGE-DETECTION-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			A general digital input can be enabled to trigger an interrupt on a falling, rising or both edges of an input signal. A clock, compare or count input on a timer can be programmed to increase, decrease or store the timer value if a change on the input pin has occurred. The condition for this change can be programmed to trigger an event  in the same manner as for a digital input.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::DigitalIO -->
	<xsd:complexType name="DIGITAL-IO" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Digital Input/Output peripherals provide the capability to send/receive data in a digital manner. Each digital input has an electrical range. When the voltage is less than a specified level, the input is represents logical low &apos;0&apos;. On the opposite when the voltage is higher than a specified value the input represents logical high &apos;1&apos;. A digital I/O can usually be programmed to be either an input or output. It can also be programmed to logically invert the input or output. The maximum frequency of a digital input or output is related to how fast the PU can read or write to the digital I/O register. It&apos;s very common for a digital I/O to have different functionality. One example is when a timer has an external clock signal associated with a digital I/O. In this case the maximum frequency is defined by the performance of the timer counter and can be found in the electrical characteristic of the peripheral datasheet.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
			<xsd:group ref="AR:DIGITAL-IO"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="DIGITAL-IO-EDGE-DETECTION-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="RISING"/>
			<xsd:enumeration value="FALLING"/>
			<xsd:enumeration value="RISING-FALLING"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Peripherals::PWD -->
	<xsd:group name="PWD">
		<xsd:annotation>
			<xsd:documentation>
			Pulse Width Demodulation is the inverse method of PWM. Here the processing unit is trying to gather information about a signal. A PWD can detect rising and falling edges and call the software in order to calculate the pulse width. When a PWD have more than one input signal the frequency and phase between the signals can be obtained.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MODE" type="AR:PWD-MODE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			A Pulse Width Demodulation peripheral can be configured to decode a two phase or a three phase input signals.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PHASE-DETECTION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Some timers have the possibility to detect signals from a quadrature rotating switch. There are two outputs signal from such a switch; the signals are 90 degrees phase shifted from each other. The rotation of the switch can then automatically be detected by a special function in a timer.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Peripherals::PWD -->
	<xsd:complexType name="PWD" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pulse Width Demodulation is the inverse method of PWM. Here the processing unit is trying to gather information about a signal. A PWD can detect rising and falling edges and call the software in order to calculate the pulse width. When a PWD have more than one input signal the frequency and phase between the signals can be obtained.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
			<xsd:group ref="AR:PULSE-WIDTH-PERIPHERAL"/>
			<xsd:group ref="AR:PWD"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Peripherals::PulseWidthPeripheral -->
	<xsd:group name="PULSE-WIDTH-PERIPHERAL">
		<xsd:annotation>
			<xsd:documentation>
			Common elements for PWM, PWD and CCU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="RESOLUTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the data width of the counter.
Unit: Bits
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="PWD-MODE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="TWO-PHASE-INPUT"/>
			<xsd:enumeration value="THREE-PHASE-INPUT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Peripherals::PWM -->
	<xsd:complexType name="PWM" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pulse Width Modulation refers to a method of carrying information on a train of pulses, the information being encoded in the width of the pulses. The frequency is normally not changed. It&apos;s only relationship between the high and low level of the signal which are changed. A PWM interface is usually a part of a processing unit. It provides the capability to communicate with another system with an easy protocol.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PERIPHERAL"/>
			<xsd:group ref="AR:PULSE-WIDTH-PERIPHERAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class Peripherals::ECUCommunicationPort -->
	<xsd:complexType name="ECU-COMMUNICATION-PORT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A specialization of a Communication HW Port that is availabe for the inter ECU communication.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-PORT"/>
			<xsd:group ref="AR:PERIPHERAL-HW-PORT"/>
			<xsd:group ref="AR:COMMUNICATION-HW-PORT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ECU-COMMUNICATION-PORT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ECU-COMMUNICATION-PORT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUElectronics::BusTermination -->
	<xsd:group name="BUS-TERMINATION">
		<xsd:annotation>
			<xsd:documentation>
			In order to avoid signal reflection and oscillation of the Technical Signal represen-tation the impedance on communication lines have to be defined and matched at the signal destination and the signal source.
Some examples:
A High-speed CAN network with a twisted pair cable works optimal with an overall impedance of 60 Ohms represented by a 120 Ohm resistor in the ECU at the begin-ning of the network and 120 Ohm in the ECU at the end of a linear network topology.
For Low-speed CAN networks in many cases termination resistors of 820 Ohm each are distributed on several ECUs to get good balance between system scalability and signal integrity in real networks without a fixed network topology. The lower bandwidth can tolerate some impedance mismatch.
For LIN networks recessive termination is used: The inactive bus signal level is defined by resistors tied to a defined voltage level.
An important attribute for communication lines is the presence of a termination resistor and the value of this resistor.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTIVE-SWITCHABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Switchable termination describes a technology were the termination resistors can be switched or changed by extra hardware and therefore is under control of software. Main scope of a switchable termination is to adopt the termination of an individual ECU to the network topology of a specific car, e. g modules for extra car options can use this method to be incorporated in a wide range of different car types. The active termination is described by the values for each termination value. E.g. 120, 820, 12k. No termination is represented by values greater than 100 k. The attributes value and switchable are exclusive to each other.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CHOKE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			To improve the signal integrity on communication busses with a differential electrical signal representation on the physical layer, common mode chokes are used. They suppress common mode DC noise on CAN, FlexRay and Ethernet networks. Depending on the network topology common mode chokes of an ECU have to be taken in to account when adding ECUs to a network during design phase. Typically chokes are used on CAN, FlexRay, LVDS.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="EMC-FILTER" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			To improve the EMC behaviour of communication busses common dedicated EMC Filters are used. They suppress frequencies outside the range, which is needed for the communication of the specific bus
E.g. some small capacitors in parallel to ground, resistors and inductivities in series are added to the bus lines in order to prevent the higher harmonics stimulated by the communication on the network
The information about the termination is used with in the system configuration process, where the placement of an ECU within a car architecture is generated.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SPLIT" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describe a technology were the termination is split in to individual resistors with a  capacitive coupling to ground. This technology improves the signal quality.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="VALUE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describe the nominal Value of the termination resistor at the ECU as seen from the communication network.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::BusTermination -->
	<xsd:complexType name="BUS-TERMINATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			In order to avoid signal reflection and oscillation of the Technical Signal represen-tation the impedance on communication lines have to be defined and matched at the signal destination and the signal source.
Some examples:
A High-speed CAN network with a twisted pair cable works optimal with an overall impedance of 60 Ohms represented by a 120 Ohm resistor in the ECU at the begin-ning of the network and 120 Ohm in the ECU at the end of a linear network topology.
For Low-speed CAN networks in many cases termination resistors of 820 Ohm each are distributed on several ECUs to get good balance between system scalability and signal integrity in real networks without a fixed network topology. The lower bandwidth can tolerate some impedance mismatch.
For LIN networks recessive termination is used: The inactive bus signal level is defined by resistors tied to a defined voltage level.
An important attribute for communication lines is the presence of a termination resistor and the value of this resistor.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:BUS-TERMINATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUElectronics::Clock -->
	<xsd:group name="CLOCK">
		<xsd:annotation>
			<xsd:documentation>
			The clock delivers the time for the PU and other HW Elements on the ECU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ADJUSTABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines if the clock is adjustable from software.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CLOCK-JITTER" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The short-term deviation of the nominal frequency to the real frequency. Jitter is influenced by the circuitry itself, voltage spikes etc. Jitter is critical for communication elements. PLL need/generate jitter for operation. Therefore communication interfaces should operate from an oscillator e.g. quartz directly or use only divider, not a PLL, as clock source. Using PLL for communication interfaces is a very common source for problems in ECU test and integration.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CLOCK-STARTUP-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The time the clock generation needs to deliver a stable and valid signal.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CLOCK-TOLERANCE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The long-term deviation of the nominal frequency to the real frequency. Influenced by manufacturing, layout, temperature, external components and voltage. Tolerances are critical for timer application and time synchronisation.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="FREQUENCY" type="AR:FREQUENCY-RANGE" minOccurs="0"/>
			<xsd:element name="OSCILLATOR-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="OSCILLATOR-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:OSCILLATOR--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="TYPE" type="AR:CLOCK-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines if a PLL or a divides is used to create the clock signal.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::Clock -->
	<xsd:complexType name="CLOCK" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The clock delivers the time for the PU and other HW Elements on the ECU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:ECU-ELECTRONICS"/>
			<xsd:group ref="AR:CLOCK"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="CLOCK--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CLOCK"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUElectronics::ECUElectronics -->
	<xsd:group name="ECU-ELECTRONICS">
		<xsd:annotation>
			<xsd:documentation>
			The abstract class ECU Electronics HW Element contains all elements and attributes common for all kind of ECU Electronics.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CAN-BE-DISABLED" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines if the ECU Electronic can be enabled and disabled.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="CLOCK-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PLL"/>
			<xsd:enumeration value="DIVIDER"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUElectronics::CommunicationTransceiver -->
	<xsd:group name="COMMUNICATION-TRANSCEIVER">
		<xsd:annotation>
			<xsd:documentation>
			The Communication Transceiver has to transfer and receive the data through the physical link and is the implementation of the OSI layer 1. Communication Transceivers have additional links to the controller/PU to support wake-up feature, enabling/disabling and error indication.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACCEPTANCE-FILTER" type="AR:COMMUNICATION-FILTER" minOccurs="0"/>
			<xsd:element name="ARCHITECTURE" type="AR:COMMUNICATION-TRANSCEIVER-ARCHITECTURE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Distinguish between different implementations.
- Master: Defines the position within the ECU, as the main controlling unit. The master defines the schedules and controls the telegram traffic.
- Slave: Reacts only on request from the master
- Multi Master: The PU has to share the external Interface with other PU. No specific master is defined by hardware.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="REJECTION-FILTER" type="AR:COMMUNICATION-FILTER" minOccurs="0"/>
			<xsd:element name="TERMINATION" type="AR:BUS-TERMINATION" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::CommunicationTransceiver -->
	<xsd:complexType name="COMMUNICATION-TRANSCEIVER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The Communication Transceiver has to transfer and receive the data through the physical link and is the implementation of the OSI layer 1. Communication Transceivers have additional links to the controller/PU to support wake-up feature, enabling/disabling and error indication.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:ECU-ELECTRONICS"/>
			<xsd:group ref="AR:COMMUNICATION-TRANSCEIVER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMMUNICATION-TRANSCEIVER-ARCHITECTURE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MASTER"/>
			<xsd:enumeration value="SLAVE"/>
			<xsd:enumeration value="MULTI-MASTER"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class ECUElectronics::DiscreteECUElectronics -->
	<xsd:complexType name="DISCRETE-ECU-ELECTRONICS" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:ECU-ELECTRONICS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUElectronics::PowerDriverHWElement -->
	<xsd:group name="POWER-DRIVER-HW-ELEMENT">
		<xsd:annotation>
			<xsd:documentation>
			Power Driver HW Element describes a group of electronic devices, which perform signal transformations with hardware devices. The main focus of the ECU Resource Template is the logical description of these elements, necessary for the system generation and relevant for the SW development.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CURRENT-LIMITATION" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device limits the maximum current conduction. The limit has to be specified. If this element does not occur the HW Element does not provide current limitation.
Unit: Ampere
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DEFAULT-RESET-BEHAVIUOR" type="AR:POWER-DRIVER-HW-ELEMENT-DEFAULT-RESET-BEHAVIUOR-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			- Passive: HW Element does not have an influence on ECU electronics (Tri-State).
- On: The HW Element supplies other electronics with power e.g. the switch is closed.
- Off: HW Element does not supply other electronics with power e.g. the switch is open.
- Other: The HW Element has a complex behaviour and must be described by other means.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NOTIFICATION" type="AR:POWER-DRIVER-NOTIFICATION" minOccurs="0"/>
			<xsd:element name="ON-STATE-RESISTANCE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The resistance in ON state can be used together with the current through this element to determine the static thermal power dissipation of the element itself and the ECU completely by summing up each element with power dissipation.
As the heating up of an power element follows with an exponential delay, the ratio of on and off times is later needed in the system generation process.
This information can give the first hint on critical issues of thermal design, but does not replace a complete static and dynamic verification of the thermal layout.
Unit: Ohm
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="POWER-DRIVER-TYPE" type="AR:POWER-DRIVER-HW-ELEMENT-POWER-DRIVER-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the general type of the element. Type is a most common naming for an element. Several sets of types exist. Type is mandatory for the usage of the ECU Resource Template.
Examples are:
- High Side Switch (HS): Power supply is switched
- Low Side Switch (LS): GND is switched
- Half Bridge (HB): Both Power and GND can be switched exclusive
- Full-Bridge (FB): Current direction in load can be alternated
- Other: Different and complex functions can be included. Examples are Power ASICs that combine smart power devices within one package.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PROTECTION" type="AR:POWER-DRIVER-PROTECTION" minOccurs="0"/>
			<xsd:element name="RESET-ON-FAULT-BEHAVIOUR" type="AR:POWER-DRIVER-HW-ELEMENT-RESET-ON-FAULT-BEHAVIOUR-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describe the way the element is reactivated after a self protection sequence was entered
- Auto: The element is turned on automatically when the fault situation disappears
- Re-Trigger: The element is turned on each time a new trigger is initiated. This new trigger must be initiated by SW.
- Fold-Back: The element is turned on automatically or after a new activation trigger with a lower threshold.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::PowerDriverHWElement -->
	<xsd:complexType name="POWER-DRIVER-HW-ELEMENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Power Driver HW Element describes a group of electronic devices, which perform signal transformations with hardware devices. The main focus of the ECU Resource Template is the logical description of these elements, necessary for the system generation and relevant for the SW development.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:ECU-ELECTRONICS"/>
			<xsd:group ref="AR:POWER-DRIVER-HW-ELEMENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="POWER-DRIVER-HW-ELEMENT-RESET-ON-FAULT-BEHAVIOUR-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="AUTO"/>
			<xsd:enumeration value="RE-TRIGGER"/>
			<xsd:enumeration value="FOLD-BACK"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="POWER-DRIVER-HW-ELEMENT-DEFAULT-RESET-BEHAVIUOR-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PASSIVE"/>
			<xsd:enumeration value="ON"/>
			<xsd:enumeration value="OFF"/>
			<xsd:enumeration value="OTHER"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="POWER-DRIVER-HW-ELEMENT-POWER-DRIVER-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="HS"/>
			<xsd:enumeration value="LS"/>
			<xsd:enumeration value="HB"/>
			<xsd:enumeration value="FB"/>
			<xsd:enumeration value="OTHER"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUElectronics::PowerDriverNotification -->
	<xsd:group name="POWER-DRIVER-NOTIFICATION">
		<xsd:annotation>
			<xsd:documentation>
			Describe the status which cause a notification to the controlling devices of an ECU, e.g. to the PU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ISSUED-INTERRUPT-SOURCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:INTERRUPT-PRODUCE-HW-PORT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="LOSS-OF-GROUND" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device detected a loss of ground situation. The device was forced off, in order to avoid damages by excessive currents.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-CURRENT" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device detected a too high current.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-VOLTAGE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device detected a too high supply voltage.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-CURRENT" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device detected a too low curent.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-VOLTAGE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device detected a too low supply voltage.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OPEN-LOAD" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device detected open loads. This situation is reported to the controlling portion of an ECU, e.g. to the PU.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OVER-TEMPERATURE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maximum allowed temperature was detected in the device. A protecting hardware has forced the device off.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SHORT-LOAD" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device was forced off, in order to avoid damages by excessive currents.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SHORT-TO-BATT" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device detected a short to battery situation. The device was forced off, in order to avoid damages by excessive currents.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SHORT-TO-GROUND" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The device detected a short to ground situation. The device was forced off, in order to avoid damages by excessive currents.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::PowerDriverNotification -->
	<xsd:complexType name="POWER-DRIVER-NOTIFICATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Describe the status which cause a notification to the controlling devices of an ECU, e.g. to the PU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:POWER-DRIVER-NOTIFICATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUElectronics::PowerDriverProtection -->
	<xsd:group name="POWER-DRIVER-PROTECTION">
		<xsd:annotation>
			<xsd:documentation>
			The Power Driver HW Element / ASIC turns off by internal means in order to protect the device against severe damages.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="LOSS-OF-GROUND-PROTECTION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Is protected against loss of ground.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-CURRENT-PROTECTION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximal current limits are exceeded.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-VOLTAGE-PROTECTION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximal voltage limits are exceeded.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-CURRENT-PROTECTION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Minimal current limits are exceeded.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-VOLTAGE-PROTECTION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Minimal voltage limits are exceeded.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OVER-TEMPERATURE-PROTECTION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Is protected against over-temperature.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="REVERSE-BATTERY-PROTECTION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Is protected against reverse battery voltage.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::PowerDriverProtection -->
	<xsd:complexType name="POWER-DRIVER-PROTECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The Power Driver HW Element / ASIC turns off by internal means in order to protect the device against severe damages.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:POWER-DRIVER-PROTECTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUElectronics::PowerDriverHWPort -->
	<xsd:group name="POWER-DRIVER-HW-PORT">
		<xsd:annotation>
			<xsd:documentation>
			Define the option of a Power Driver that the output of a Power Driver can be superposed by a PWM signal asserted by a HW Element e.g. a microprocessor. 
In most cases, the PWM signal is connected by a separate wire, even when the general control information are transmitted by a bus.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PWM-MAX-FREQUENCY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			It defines the upper limit at which the device can fulfil the PWM capability.
EMC and power dissipation are increasing almost exponential with the PWM frequency. Choosing PWM frequencies be aware that some effects can cause secondary effects, which can create a audible noise for the user, e.g. a PWM dimmed lamp can be noticed by the driver.
Unit: Hz
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PWM-MIN-OFF-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the characteristic, that a Power Driver has to be off at least a minimum time in order to assure the function.
Unit: s
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PWM-MIN-ON-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the characteristic, that a Power Driver has to be on at least a minimum time in order to assure the function.
Unit: s
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::PowerDriverHWPort -->
	<xsd:complexType name="POWER-DRIVER-HW-PORT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Define the option of a Power Driver that the output of a Power Driver can be superposed by a PWM signal asserted by a HW Element e.g. a microprocessor. 
In most cases, the PWM signal is connected by a separate wire, even when the general control information are transmitted by a bus.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-PORT"/>
			<xsd:group ref="AR:POWER-DRIVER-HW-PORT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUElectronics::PowerSupplyCurrentNotification -->
	<xsd:group name="POWER-SUPPLY-CURRENT-NOTIFICATION">
		<xsd:sequence>
			<xsd:element name="HYSTERESIS" type="xsd:double" minOccurs="0"/>
			<xsd:element name="INTERRUPT-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="INTERRUPT-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:INTERRUPT-PRODUCE-HW-PORT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="LEVEL" type="xsd:double" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::PowerSupplyCurrentNotification -->
	<xsd:complexType name="POWER-SUPPLY-CURRENT-NOTIFICATION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:POWER-SUPPLY-CURRENT-NOTIFICATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUElectronics::PowerSupplyHWElement -->
	<xsd:group name="POWER-SUPPLY-HW-ELEMENT">
		<xsd:annotation>
			<xsd:documentation>
			The Power Supply HW Element provides information about the power source of the ECU. There can be multiple power supplies within one ECU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BACKUP-CAPACITY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Define the capability assigned to the output of the Power Supply HW Element to maintain the output voltage stable for a certain time after the undervoltage status information is asserted.
In the ECU Resource Template the Backup Capacity is described as time. The time is dependent from the current consumed by the HW Elements connected to the according output, the SW-functions controlling the ECU hardware and the implementation of the Power Supply HW Element itself. The time has to be calculated from the available capacitors or measured in the application.
Example: For the energy storage for airbag applications capacitors stores energy for the airbag ignition for several seconds even the battery is completely disconnected.
Example: A combined step up/step down DC/DC converter can deliver a stable 5V volt output even when the input has already dropped to 3V. The undervoltage status is already set at a Vbatt level of 6V.
Unit: Ah
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DEFAULT-VOLTAGE-ON-RESET" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This value defines the nominal output voltage, which is supplied as default after a reset occured. This attribute is only applicable at power supplies with a programmable output voltage.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-VOLTAGE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maximum voltage that can be supplied.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-VOLTAGE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The minimum voltage that can be supplied.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NOTIFICATION-OVER-TEMPERATURE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Status information that the on-chip temperature on the Power Supply Hardware Element exceed the maximal, defined limit.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NOTIFICATION-RESET" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The power on reset is generated depending on the output voltage. Valid operation of the ECU and the connected HW Elements are only possible if the output voltage is stable and within the specified output voltage range. Therefore most of the Power Supply HW Elements contain a circuitry, which generate a output signal which indicates an instable or unspecified voltage at the output. Some Power Supply HW Elements offer the possibility to adjust the reset thresholds.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OVER-CURRENT-NOTIFICATION" type="AR:POWER-SUPPLY-CURRENT-NOTIFICATION" minOccurs="0"/>
			<xsd:element name="OVER-VOLTAGE-NOTIFICATION" type="AR:POWER-SUPPLY-VOLTAGE-NOTIFICATION" minOccurs="0"/>
			<xsd:element name="RESET-DELAY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The reset signal at the power-on reset is delayed by the Power Supply HW Element in order to enable the different ECU HW Elements to enter a stable and defined operation state when the reset signal is released.
Unit: s
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESET-ON-FAULT-BEHAVIOUR" type="AR:POWER-SUPPLY-HW-ELEMENT-RESET-ON-FAULT-BEHAVIOUR-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describe the way the element is reactivated after a self protection sequence was entered
- Auto: The element is turned on automatically when the fault situation disappears
- Re-Trigger: The element is turned on each time a new trigger is initiated. This new trigger must be initiated by SW.
- Fold-Back: The element is turned on automatically or after a new activation trigger with a lower threshold.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="UNDER-VOLTAGE-NOTIFICATION" type="AR:POWER-SUPPLY-VOLTAGE-NOTIFICATION" minOccurs="0"/>
			<xsd:element name="WAKEUP-CAPABILITY" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describes the feature of the power supply to turn on the output voltage by an external event. In some cases this feature is coupled with other ECU internal HW elements e.g. transceivers and is the main feature used by the car specific power management. Different to other HW elements with this feature the power supply is the receiver of the signal, as more ECU function is only possible if the power supply is activated. Example: Philips CAN Transceivers have an output called INH, which allow together with some Voltage regulators with wake up capability to wake up the ECU at the presence of a CAN bus telegram. 
Example: The Wake up Capability is connected to the terminal KL15 (ignition), the ECU is waked up at the presence of KL15.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::PowerSupplyHWElement -->
	<xsd:complexType name="POWER-SUPPLY-HW-ELEMENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The Power Supply HW Element provides information about the power source of the ECU. There can be multiple power supplies within one ECU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:ECU-ELECTRONICS"/>
			<xsd:group ref="AR:POWER-SUPPLY-HW-ELEMENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="POWER-SUPPLY-HW-ELEMENT-RESET-ON-FAULT-BEHAVIOUR-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="AUTO"/>
			<xsd:enumeration value="RE-TRIGGER"/>
			<xsd:enumeration value="FOLD-BACK"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUElectronics::PowerSupplyVoltageNotification -->
	<xsd:group name="POWER-SUPPLY-VOLTAGE-NOTIFICATION">
		<xsd:sequence>
			<xsd:element name="HYSTERESES" type="xsd:double" minOccurs="0"/>
			<xsd:element name="INTERRUPT-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="INTERRUPT-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:INTERRUPT-PRODUCE-HW-PORT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="LEVEL" type="xsd:double" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::PowerSupplyVoltageNotification -->
	<xsd:complexType name="POWER-SUPPLY-VOLTAGE-NOTIFICATION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:POWER-SUPPLY-VOLTAGE-NOTIFICATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUElectronics::PowerSupplyHWPort -->
	<xsd:group name="POWER-SUPPLY-HW-PORT">
		<xsd:annotation>
			<xsd:documentation>
			The Power Supply HW Port is used to model the power distribution within the ECU. If the direction is &quot;in&quot; the port is used to describe the power consumption of an HW Element. If the direction is &quot;out&quot; the port is used to describe a power source. The HW Connection between these two HW Ports can only be established between the Power Supply HW Port of the HW Element with direction &quot;out&quot; and a Power Supply HW Port of the Power Supply HW Element with direction &quot;in&quot;.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CAN-BE-SWITCHED-OFF" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines if the Power Supply HW Port can be switched off and therefore the supplied HW Element is switched off as well. This feature allows to describe which parts of an ECU are able be disconnected from their power supply based on software interaction. 
If the Power Supply HW Port has the direction &apos;in&apos; the supplied HW Element can be switched off. 
If the Power Supply HW Port has the direction &apos;out&apos; the power supply can be switched off and therefore all supplied HW Elements are switched off as well (This is used to describe groups of HW Elements that can only be switched off together). 
When however the whole ECU is disconnected from power the switchable power supply is of course not valid anymore.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SUPPLIED" type="AR:ELECTRICAL-RANGE" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::PowerSupplyHWPort -->
	<xsd:complexType name="POWER-SUPPLY-HW-PORT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The Power Supply HW Port is used to model the power distribution within the ECU. If the direction is &quot;in&quot; the port is used to describe the power consumption of an HW Element. If the direction is &quot;out&quot; the port is used to describe a power source. The HW Connection between these two HW Ports can only be established between the Power Supply HW Port of the HW Element with direction &quot;out&quot; and a Power Supply HW Port of the Power Supply HW Element with direction &quot;in&quot;.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-PORT"/>
			<xsd:group ref="AR:POWER-SUPPLY-HW-PORT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="OSCILLATOR-OSCILLATOR-MODE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="FUNDAMENTAL"/>
			<xsd:enumeration value="OVERTONE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUElectronics::Oscillator -->
	<xsd:group name="OSCILLATOR">
		<xsd:annotation>
			<xsd:documentation>
			The basic source for time in the ECU. Based on the oscillator the PU clock is generated, but also the communication and other peripherals need timing information (ADC, PWM, timer).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ADJUSTIBLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines if the oscillator is adjustable from software.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="BACKUP-OSCILLATOR" type="AR:OSCILLATOR" minOccurs="0"/>
			<xsd:element name="OSCILLATOR-FREQUENCY-RANGE" type="AR:FREQUENCY-RANGE" minOccurs="0"/>
			<xsd:element name="OSCILLATOR-JITTER" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The short-term deviation of the nominal frequency to the real frequency. Jitter is influenced by the circuitry itself, voltage spikes etc. Jitter is critical for communication elements.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OSCILLATOR-MODE" type="AR:OSCILLATOR-OSCILLATOR-MODE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Crystals and other oscillating elements have more than one resonant frequencies, which are usually odd harmonics to the basic, fundamental frequencies. For Automotive a basic requirement should be to use only fundamental mode only. Using overtone modes there is a risk, that the oscillator circuitry starts at the fundamental mode after a error in the start up routine. In order to reach an overtone mode the frequency of the fundamental mode, or lower overtones has to be passed during start up. There is a risk that the oscillator locks to this, lower frequency. Therefore Fundamental modes oscillatorts are not so critical for this issue. Fundamental quartz/crystals can reach up to 40 MHz today, above this frequency all quartz/crystals are running in the 3rd, 5th or higher overtone mode.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OSCILLATOR-STARTUP-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The time the oscillator needs to deliver a stable and valid signal.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OSCILLATOR-TOLERANCE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The long-term deviation of the nominal frequency to the real frequency. Influenced by manufacturing, layout, temperature, external components and voltage. Tolerances are critical for timer application and time synchronisation.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUElectronics::Oscillator -->
	<xsd:complexType name="OSCILLATOR" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The basic source for time in the ECU. Based on the oscillator the PU clock is generated, but also the communication and other peripherals need timing information (ADC, PWM, timer).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:ECU-ELECTRONICS"/>
			<xsd:group ref="AR:OSCILLATOR"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="OSCILLATOR--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="OSCILLATOR"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ProcessingUnit::InterruptConsumeHWPort -->
	<xsd:group name="INTERRUPT-CONSUME-HW-PORT">
		<xsd:annotation>
			<xsd:documentation>
			This port represents the drain of an interrupt request, i.e. the HWElement (in the majority of cases this will be a ProcessingUnit) to which this HWPort is attached is capable of accepting interrupt requests.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTIVATION-SOURCE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines which hardware resource activate the interrupt. Typically any peripheral HW Element  can activate an interrupt.  E.g. CAN, SCI, SPI, Timer, ADC. Even simple digital I/O can activate an interrupt. Some microC have in this context dedicatated pins which act only as activation for interrupt. The connection from the according HW Element is made by the HW Port.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="LATENCY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Interrupt Latency: time passed from the occurrence of the interrupt request until the interrupt service routine is entered
- HW: Register organisation; operations are necessary for context save.
- SW: As SW can control the enabling/disabling of the interrupt SW determines a great part of the according time.
- System: several constraints define the min/max times allowed for software to enable / disable interrupts.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MASKABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines if interrupts can be selected to be processed by the interrupt controller.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PRIORITY" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Some processing units offer different interrupt levels. It describes the priority in which the incoming interrupts are handled.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ProcessingUnit::InterruptConsumeHWPort -->
	<xsd:complexType name="INTERRUPT-CONSUME-HW-PORT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This port represents the drain of an interrupt request, i.e. the HWElement (in the majority of cases this will be a ProcessingUnit) to which this HWPort is attached is capable of accepting interrupt requests.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-PORT"/>
			<xsd:group ref="AR:INTERRUPT-CONSUME-HW-PORT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ProcessingUnit::MPU -->
	<xsd:group name="MPU">
		<xsd:annotation>
			<xsd:documentation>
			A MPU provides means where the memory access within a defined program flow of a PU is controlled. In case of a failure an exception routine e.g. interrupt is activated.
A MPU is implemented as an independent hardware block in a device separate to the processing unit. A MPU does not perform any data manipulation, only in case of an error a change in the processor control flow is forced.
The number of individual checked memory ranges is limited to the registers available for specifying the memory ranges. One individual memory range is in the following referenced as MPU Channel.
In most cases the MPU consists of a set of registers, which do range checking of the addresses asserted by the program on the address bus as well as the access type to the according address. The checking of the address ranges is also coupled to the address range of the program, which runs under the control of the MPU.
The MPU also can be coupled with one of the different processing elements of a device like the PU itself, a DMA or a Coprocessor.
In order to have a broad usage of a MPU a specification of filter values is often allowed, so very user specific selection methods are possible.
Typical use case for a MPU: A 3rd party software routine is allowed only to access a defined memory-area. Any access outside the defined memory area will be denied and control will be transferred to the supervising operating system. A error handling routine will be started.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CHANNEL-COUNT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the number of individual MPU channels are available.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PROTECTED-MEMORY-HW-PORT-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PROTECTED-MEMORY-HW-PORT-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:MEMORY-MAPPED-HW-PORT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RAISED-INTERRUPTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="INTERRUPT-PRODUCE-HW-PORT" type="AR:INTERRUPT-PRODUCE-HW-PORT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ProcessingUnit::MPU -->
	<xsd:complexType name="MPU" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A MPU provides means where the memory access within a defined program flow of a PU is controlled. In case of a failure an exception routine e.g. interrupt is activated.
A MPU is implemented as an independent hardware block in a device separate to the processing unit. A MPU does not perform any data manipulation, only in case of an error a change in the processor control flow is forced.
The number of individual checked memory ranges is limited to the registers available for specifying the memory ranges. One individual memory range is in the following referenced as MPU Channel.
In most cases the MPU consists of a set of registers, which do range checking of the addresses asserted by the program on the address bus as well as the access type to the according address. The checking of the address ranges is also coupled to the address range of the program, which runs under the control of the MPU.
The MPU also can be coupled with one of the different processing elements of a device like the PU itself, a DMA or a Coprocessor.
In order to have a broad usage of a MPU a specification of filter values is often allowed, so very user specific selection methods are possible.
Typical use case for a MPU: A 3rd party software routine is allowed only to access a defined memory-area. Any access outside the defined memory area will be denied and control will be transferred to the supervising operating system. A error handling routine will be started.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MPU"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ProcessingUnit::ProcessingUnit -->
	<xsd:group name="PROCESSING-UNIT">
		<xsd:annotation>
			<xsd:documentation>
			A ProcessingUnit describes the plain processor core. The identifier provides the actual type name of the processing unit.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ADDRESSING-MODES" type="AR:PROCESSING-UNIT-ADDRESSING-MODES-ENUM" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			The addressing modes describe the options to access the data from the memory. There are several addressing modes possible. Typical attributes are:
- Direct
- Indirect
- Absolute
- Base + offset (relative)
- Near / far
- Pre/Post- Increment/decrement
The addressing modes take important influence to the performance index of a PU, but are not main topic of the software development, as far as high level programming languages are used, due to the fact that these are covered by compiler settings and compiler strategies. The main advantage is available at the level of assembler programming or compiler optimization.
The Enumeration is open.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ARCHITECTURE-KIND" type="AR:PROCESSING-UNIT-ARCHITECTURE-KIND-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			There are two kinds of architectures:
- Harvard: A computer architecture in which program instructions are stored in different memory from data. Each type of memory is accessed via a separate bus, allowing instructions and data to be fetched in parallel.
- Von Neumann: A computer architecture in which each successive operation can read or write any memory location, independent of the location accessed by the previous operation.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ARCHITECTURE-NAME" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The name of the architecture (e.g. ARM, MIPS, PowerPC).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ARCHITECTURE-TYPE" type="AR:PROCESSING-UNIT-ARCHITECTURE-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The architecture type take influence to the performance index of a PU, but are not necessarily a main topic of software development, as some of the aspects are transparent  to the user as the are handled with in the compiler. The last two types are slightly different as they require a detailed planning during system design, how the data must be prepared in order to use the features of an SIMD or MIMD very efficiently. Application like video processing use in general this features by their data format, as every pixel information is formed by the three basic colours and intensity, thus each pixel is represented by four different values, which have to be processed simultaneously.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="BOOT-TIME" type="AR:BOOT-TIME" minOccurs="0"/>
			<xsd:element name="DMA-CHANNEL-COUNT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Direct Memory Access is a mechanism for off-loading a PU and having transfer directly between memory and peripherals without involving the PU. 
In most common PU the DMA mechanism is implemented with a specialised cell (DMA unit) that transfers data between a peripheral device and memory, independent of the processor. The DMA controller becomes the bus master and directs the reads or writes between itself and memory. A typical DMA transfer can be described in three steps:
1. The PU sets up the DMA transfer by supplying the identity of the periphery module, the operation to perform on that device, the memory address that is the source or the destination of the data to be transferred, and the number of bytes to transfer. 
2. The DMA starts the operation on the periphery device and arbitrates for the bus. When the data is available, from the periphery device or memory, it transfers the data. The DMA unit supplies the memory address and initiates the next transfer. With this technique, a DMA unit can complete an entire transfer, which may be Kbytes of data, without bothering the PU. Many DMA units contain some memory to allow them to deal flexibly with delays either in transfer or those incurred while waiting to become bus master. 
3. Once the DMA transfer is complete, the DMA unit interrupts the processor, which can then determine by interrogating the DMA unit or examining memory whether the entire operation completed successfully. 
During an active DMA transfer the PU cannot access the involved resources concurrently.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="IMPLEMENTATION-TECHNOLOGY" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Name of the technology used to implement this PU.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-INTERRUPT-NESTING-LEVELS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines how many interrupts are allowed to be activated at one time. This entry is mainly defined by the size of the according stack as the data saving mechanism during interrupts and the data passing mechanism during function calls use the stack.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MPU" type="AR:MPU" minOccurs="0"/>
			<xsd:element name="NATURAL-DATA-SIZE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The natural data size prvides information which data manipulations are optimized on this PU. The natural data size is typically the Data Register size. The PU is optimised for this data size.
Typical natural data size is one of following (in bits): 8, 16, 32, 64, other (12, 20, 80)

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OPCODE-SIZE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The attribute describes the typical length of the opcodes. In CISC machines the opcode size is variable due to the opcode itself. In RISC machines the opcode is by definition limited to a defined size.
Type definition is used if the PU has more than one opcode set is incorporated. E.g. at the ARM architecture there is the ARM opcode set (size of 32 bit) and the Thumb opcode set (size of 16 bit).
Code compression is a technology where the opcodes are stored in a compressed form and are automatically decompressed before execution.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PU-CLOCK" type="AR:CLOCK" minOccurs="0"/>
			<xsd:element name="REGISTER-MODELS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="REGISTER" type="AR:REGISTER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SPECIAL-OPCODES" type="AR:PROCESSING-UNIT-SPECIAL-OPCODES-ENUM" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			The following attributes are opcodes, which are not supported by all PUs. The support of this opcodes has an influence on the performance of the PU.
- Bit-manipulation
- Multiplication
- Division
- Multiply Accumulate
- Floating-point Support
In the future further opcodes may be possible.

The special opcodes  take important influence to the performance index of a PU, but are not main topic of the software development, as far as high level programming languages are used, due to the fact that these are covered by compiler settings, compiler strategies and software libraries where the direct usage or a SW emulation is available for almost any general use case. For some of these opcodes the main advantage is available only at the level of assembler programming or compiler optimization.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SUPPORTED-DATA-TYPES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SUPPORTED-DATA-TYPE" type="AR:SUPPORTED-DATA-TYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ProcessingUnit::ProcessingUnit -->
	<xsd:complexType name="PROCESSING-UNIT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A ProcessingUnit describes the plain processor core. The identifier provides the actual type name of the processing unit.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PROCESSING-UNIT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="PROCESSING-UNIT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PROCESSING-UNIT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="PROCESSING-UNIT-ARCHITECTURE-KIND-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="HARVARD"/>
			<xsd:enumeration value="V-NEUMANN"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="PROCESSING-UNIT-SPECIAL-OPCODES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="BIT-MANIPULATION"/>
			<xsd:enumeration value="MUL"/>
			<xsd:enumeration value="DIV"/>
			<xsd:enumeration value="MAC"/>
			<xsd:enumeration value="FLOAT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="PROCESSING-UNIT-ADDRESSING-MODES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="DIRECT"/>
			<xsd:enumeration value="INDIRECT"/>
			<xsd:enumeration value="INDEXED"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="PROCESSING-UNIT-ARCHITECTURE-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="RISC"/>
			<xsd:enumeration value="CISC"/>
			<xsd:enumeration value="SIMD"/>
			<xsd:enumeration value="MIMD"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ProcessingUnit::SupportedDataType -->
	<xsd:group name="SUPPORTED-DATA-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			This element provides a list of all supported data types and its according data sizes of the described PU.
Examples: Boolean (1, 8 bit), Bit String / Bit Field (x bit), Character (8, 16 bit), Signed / unsigned integer (8, 16, 24, 32, 48, 64 bit), Single / double float (56, 64 bit), Fixed point (24 bit), Fractional, Packed (two values handled in one register)
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SUPPORTED-DATA-SIZE" type="xsd:integer" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			The size of the data type.
Unit: Bit
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ProcessingUnit::SupportedDataType -->
	<xsd:complexType name="SUPPORTED-DATA-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element provides a list of all supported data types and its according data sizes of the described PU.
Examples: Boolean (1, 8 bit), Bit String / Bit Field (x bit), Character (8, 16 bit), Signed / unsigned integer (8, 16, 24, 32, 48, 64 bit), Single / double float (56, 64 bit), Fixed point (24 bit), Fractional, Packed (two values handled in one register)
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SUPPORTED-DATA-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ProcessingUnit::Register -->
	<xsd:group name="REGISTER">
		<xsd:annotation>
			<xsd:documentation>
			The user available registers are a part of the programming model that consists of: Memory organisation and segmentation, Data types, Registers, Instruction format, Operand selection, Interrupts and exceptions.
Basically the register model contains the registers that are interest to the applications programmer; these registers can be grouped into three basic categories:
- General registers: These general-purpose registers are used primarily to contain operands for arithmetic and logical operations.
- Segment registers: These special-purpose registers permit software designers to choose either a flat or segmented model of memory organisation. These registers determine, at any given time, which segments of memory are currently addressable.
- Status and instruction registers: These special-purpose registers are used to record and alter certain aspects of the processor state.

The register model is only valuable data for low level programming, e.g assembler programming. The register model, along with the available OP codes takes influence on the performance of the PU. The most general impact of the register model to software is number of registers which have to be handled during interrupts or function calls.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COUNT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describes how many registers are available of the specified type.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TYPE" type="AR:REGISTER-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describes the kind of register.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ProcessingUnit::Register -->
	<xsd:complexType name="REGISTER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The user available registers are a part of the programming model that consists of: Memory organisation and segmentation, Data types, Registers, Instruction format, Operand selection, Interrupts and exceptions.
Basically the register model contains the registers that are interest to the applications programmer; these registers can be grouped into three basic categories:
- General registers: These general-purpose registers are used primarily to contain operands for arithmetic and logical operations.
- Segment registers: These special-purpose registers permit software designers to choose either a flat or segmented model of memory organisation. These registers determine, at any given time, which segments of memory are currently addressable.
- Status and instruction registers: These special-purpose registers are used to record and alter certain aspects of the processor state.

The register model is only valuable data for low level programming, e.g assembler programming. The register model, along with the available OP codes takes influence on the performance of the PU. The most general impact of the register model to software is number of registers which have to be handled during interrupts or function calls.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:REGISTER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="REGISTER-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="DATA"/>
			<xsd:enumeration value="ADDRESS"/>
			<xsd:enumeration value="CONTROL"/>
			<xsd:enumeration value="STATUS"/>
			<xsd:enumeration value="STACK-POINTER"/>
			<xsd:enumeration value="SPECIAL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class ProcessingUnit::InterruptProduceHWPort -->
	<xsd:complexType name="INTERRUPT-PRODUCE-HW-PORT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This port represents the source of an interrupt request, i.e. the HWElement to which this port is attached is capable of raising interrupt requests.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-PORT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="INTERRUPT-PRODUCE-HW-PORT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="INTERRUPT-PRODUCE-HW-PORT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Memory::MemoryMappedAssemblyHWConnection -->
	<xsd:group name="MEMORY-MAPPED-ASSEMBLY-HW-CONNECTION">
		<xsd:annotation>
			<xsd:documentation>
			This connection is used to connect Memory HWPort on the same hierarchical level (inside one HW Container).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BASE-ADDRESS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the base address of the memory within the ECU template.
The same base address might be defined multiple times according to the access type and the architecture. A base address is uniquely bound to a defined memory segment.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="BYTE-ORDER" type="AR:BYTE-ORDER-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			When a PU stores data in a memory the ordering of the bytes can be done in two different ways. This storing scheme is normally fixed in the PU when more than one byte is stored in the memory. When the least significant byte is stored at the lowest address this architecture is called &quot;mostSignificantByteLast&quot; (aka little endian) and when the most significant byte is stored at the lowest address this is called &quot;mostSignificantByteFirst&quot; (aka big endian). Some CPU architectures like ARM and PowerPC can be configured to handle both little and big endian. This is called bi-endian. ByteOrder is very important when you communicate between different PUs or ECUs.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CACHABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			A memory segment may be cacheable. This has to be defined in the description of the segment connection.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="HW-CONNECTION-ACCESSS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MEMORY-ACCESS" type="AR:MEMORY-ACCESS"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SEGMENT-USAGE" type="AR:MEMORY-MAPPED-ASSEMBLY-HW-CONNECTION-SEGMENT-USAGE-ENUM" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			The segment usage is defined in the linker memory map. Usually it is fixed within an operation mode but different operations modes have different memory usage.
The element segment usage contains the following attributes. 
- Data: The attribute data is used for all kind of data: constant, variable, calibration, system initialisation, system configuration, etc. 
- Code: The attribute code is used for the program code itself. 
- Stack: Memory usable for a system or software stack is in some cases only available on limited number of segments within a PU. 
- Boot: The boot memory is used to store program and data for the start up or test of an ECU. Within the boot program the basic ECU initialisation is performed. Furthermore some system maintenance programs, like the set-up for flash programming or loading of data via communication interface, can be part of the boot program. 
Boot memory is in general not a subject of AUTOSAR SW. 
-- Boot sector: Boot sector is the location in memory, preferable Flash or ROM, where the boot program is stored. The location of the boot sector might be dependant on the PU architecture as reset and interrupt vectors must be accessible during boot. The boot sector should be separated from other user accessible Flash or implemented as ROM. In Flash the boot sector should have the appropriate array size, some few kilobyte and provide protection mechanism against unintended erasure or system manipulation.
A system may have different boot sectors, one accessible only for testing the PU during the manufacturing and configuration of the PU, in factory test mode or some initial program mode, and a user boot mode. 
-- Mapping of boot sector: Mapping of the boot sector is useful to enhance the boot sequence and the release of the used resources during the boot phase at the later user mode, e.g. the use of reset vector and interrupt vector can be improved.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Memory::MemoryMappedAssemblyHWConnection -->
	<xsd:complexType name="MEMORY-MAPPED-ASSEMBLY-HW-CONNECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This connection is used to connect Memory HWPort on the same hierarchical level (inside one HW Container).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-CONNECTION"/>
			<xsd:group ref="AR:ASSEMBLY-HW-CONNECTION"/>
			<xsd:group ref="AR:MEMORY-MAPPED-ASSEMBLY-HW-CONNECTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="MEMORY-MAPPED-ASSEMBLY-HW-CONNECTION-SEGMENT-USAGE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CODE"/>
			<xsd:enumeration value="DATA"/>
			<xsd:enumeration value="STACK"/>
			<xsd:enumeration value="BOOT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Memory::MemoryMappedDelegationHWConnection -->
	<xsd:complexType name="MEMORY-MAPPED-DELEGATION-HW-CONNECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This connection is used to delegate a Memory HW Port to the outside of a HW Container. Typically this will used internally of a micro-controller.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-CONNECTION"/>
			<xsd:group ref="AR:DELEGATION-HW-CONNECTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Memory::ProvidedMemorySegment -->
	<xsd:group name="PROVIDED-MEMORY-SEGMENT">
		<xsd:annotation>
			<xsd:documentation>
			Describes one volatile memory segment.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ALIGNMENT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Some memory architectures are organised for bigger natural data size than accessed by the PU. In this case memory might not be used completely and some memory locations are left blank due to misalignment. The overall memory size is not used by code or data.
Misalignment may be recovered by special mechanisms provided by hardware or software. In this case the access time will be increased. Certain PU architectures do not allow misalignment in code or data generally.
Unit: Byte
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ARCHITECTURAL-QUALITY" type="AR:ERROR-DETECTION-CORRECTION" minOccurs="0"/>
			<xsd:element name="MANUFACTURING-QUALITY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			As memory holds the executable program as well as the according data, memory needs a level of quality and reliability according to the purpose of the ECU. In most applications today memory is the biggest homogeneous hardware block; therefore quality and reliability of memory have the biggest impact on ECU performance and availability.
With the introduction of non-volatile memory and the use of huge DRAM memories the aspect of quality and reliability gains more importance.
Despite all Zero-defect programs of the semiconductor suppliers a defect rate in the range of 1 to 5 ppm must be considered as given even for critical applications.
Separate quality data for Endurance and Data retention can be available also. The biggest value for ppm rates is used as a quality factor.
Unit: ppm
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SEGMENT-SIZE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			A value that determines the amount of bytes within the memory segment.
An ECU for AUTOSAR always contains at least one memory segment.
Within a single ECU different memory types and access types can be used simultaneously.
An ECU may consist of different parts that carry one or more memories.
Segment size is defined in the terms of Bytes. 
The overall amount of memory is the sum of all available memory segments. For different types of memory only the sum of the same type gives a useful overall sum.
Unit: Byte
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SEPARATE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Separate memories are required for safety-relevant functions and redundancy requirements.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Memory::ProvidedMemorySegment -->
	<xsd:complexType name="PROVIDED-MEMORY-SEGMENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Describes one volatile memory segment.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PROVIDED-MEMORY-SEGMENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="PROVIDED-MEMORY-SEGMENT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PROVIDED-MEMORY-SEGMENT"/>
			<xsd:enumeration value="PROVIDED-NV-MEMORY-SEGMENT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Memory::ProvidedNVMemorySegment -->
	<xsd:group name="PROVIDED-NV-MEMORY-SEGMENT">
		<xsd:annotation>
			<xsd:documentation>
			Describes one non-volatile memory segment.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ENDURANCE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Program and erase cycles are a stress to the memory cell, therefore endurance is characterised by the number of erase/program cycles the memory can survive exceeding the prescribed failure rate.
Unit: No of cycles.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DATA-RETENTION" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Data retention time is the time between programming a sample of non-volatile memory and the observation of a prescribed failure rate when verifying the programmed pattern. The time is dependent on the chosen technology for the integrated memory cell.
Unit: Years
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MARGIN-READ-AVAILABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Additional to verify, all data are read back with a different set-up of the threshold of the sense amplifier of the programmed cell. With this method besides the logical correctness, the sufficient amount of electrical charges, which represents the stored data is checked. Furthermore the content of the memory and the correctness and the quality of the programming tools can be verified. Performing the margin read allow the prediction of the data retention. The feature of margin read is a characteristic of a memory, which is not available at all devices. Margin read is available for flash technology only.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SEGMENT-SIZE-ERASE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			For an erasable memory it&apos;s usually the same size of the segment as for the segment size which can be erased at a time. If the size of an erasable segment is different shall the size of the erasable segment be entered in the table.
Unit: Byte
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SEGMENT-SIZE-WRITE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Some memory types have not the same segment size as in the case when data is written to the memory. For example, a specific flash memory you must write 128 bytes once even if the segment size is 16 kBytes.
Unit: Byte
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Memory::ProvidedNVMemorySegment -->
	<xsd:complexType name="PROVIDED-NV-MEMORY-SEGMENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Describes one non-volatile memory segment.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:PROVIDED-MEMORY-SEGMENT"/>
			<xsd:group ref="AR:PROVIDED-NV-MEMORY-SEGMENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="MEMORY-MAPPED-HW-PORT-HW-PORT-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="UNSPECIFIED"/>
			<xsd:enumeration value="DATA"/>
			<xsd:enumeration value="CONTROL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Memory::MemoryMappedHWPort -->
	<xsd:group name="MEMORY-MAPPED-HW-PORT">
		<xsd:sequence>
			<xsd:element name="DATA-INTERFACE-WIDTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The element defines the number of bits that can be transferred from the PU to the memory device or vice versa. The width of data bus are important characteristics. All technical characteristics of the memory are covered by the access time.
Unit: Bit
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="HW-PORT-TYPE" type="AR:MEMORY-MAPPED-HW-PORT-HW-PORT-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The HW Port Type of a HW Port can be one of the following attributes 
- unspecified: The attribute is used as a placeholder in the iterative process or if a detailed specification of the HW Port is not required, for example a low-level driver supplied by the semiconductor manufacturer. 
- Data: Data is the part of the information processed later in the SW Application. 
- Control: Control is needed by the hardware and the basic SW Routines to manage the overall operation. 

The attributes Data and Control are defined in the HIS Specification.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Memory::MemoryMappedHWPort -->
	<xsd:complexType name="MEMORY-MAPPED-HW-PORT" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-PORT"/>
			<xsd:group ref="AR:MEMORY-MAPPED-HW-PORT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="MEMORY-MAPPED-HW-PORT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MEMORY-MAPPED-HW-PORT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SensorActuator::ActuatorHW -->
	<xsd:group name="ACTUATOR-HW">
		<xsd:annotation>
			<xsd:documentation>
			HW Element Actuator definition.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFAULT-POSITION-TYPE" type="AR:ACTUATOR-HW-DEFAULT-POSITION-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the way the actuator is seen after power on. On Bi-Stable or Multistable actuators the software has to know the status of this device after reset or Power On.
Each actuator has a control input that determines its behaviour
- Stable: The actuator has a unique defined position after a reset or power down. E.g. a spring force the actuator back into a start position or there are means which give a position feedback like a potentiometer or switch.
- Instable: The position of the actuator can not be specified after power on or reset or the position of the actuator can be changed by other means
- Bi-stable: The actuator has two possible, defined positions after a reset or power down. E.g. the actuator is in one of the two possible end positions. Only one of them is signalled by a feedback, e.g. a switch. The second end position is simply to be determined as the inversion of the feedback.
- Multi-stable: The actuator has more possible, defined positions after a reset or power down and they are signalled by appropriate feedback E.g. a door latch might consist of different stable states: pre-locked, locked, double locked, released, open from outside, open from inside, All this states are covered by a feedback, and the states can change in random manner after the wake-up or power-up of a car.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DEFAULT-POSITION-VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			If there is a specific default value is available. E.g. Valve status = off;
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ELECTRICAL-TYPE" type="AR:ACTUATOR-HW-ELECTRICAL-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the most typical electrical behaviour of the system. This information is necessary for the ECU generation process and for tools which check for later interaction of the different component. (avoid resonance&apos;s, planning of the ECU power management).
- Resistive: Heater, Lamp
- Inductive: Coils, Motor
- Capacitive: Extra SuperCAPS for bordnet stability
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ENDURANCE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of activation cycles the actuator is designed for.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MOVEMENT" type="AR:ACTUATOR-HW-MOVEMENT-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the way the movement is controlled by AUTOSAR. Positional feedback can be provided by the actuator by the conglomeration of the requisite actuator and sensor primitives.
- Unidirectional: The actuator is only forced in one direction by SW. e.g. eject of a tape. The user or a other mechanical system is needed to chance the status of the actuator. Other example is a motor which has a circular movement always in one direction. SW can not alter this behaviour e.g. fan, wiper.
- Bidirectional: The actuator can be moved forward and backward by software, e.g. window lift
- Unidirectional with autoreset: The actuator is controlled only one direction by electrical means and SW. Bringing the actuator in to the default position other means are available. E.g. unlock of the trunk or gasoline flap with a motor which is brought into the initial position with a spring; a relay or a valve use the same mechanism.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SensorActuator::ActuatorHW -->
	<xsd:complexType name="ACTUATOR-HW" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			HW Element Actuator definition.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:SENSOR-ACTUATOR-HW"/>
			<xsd:group ref="AR:ACTUATOR-HW"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ACTUATOR-HW-ELECTRICAL-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="RESISTIVE"/>
			<xsd:enumeration value="CAPACITIVE"/>
			<xsd:enumeration value="INDUCTIVE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="ACTUATOR-HW-MOVEMENT-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="UNIDIRECTIONAL"/>
			<xsd:enumeration value="BIDIRECTIONAL"/>
			<xsd:enumeration value="UNIDIRECTIONAL-WITH-AUTORESET"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="ACTUATOR-HW-DEFAULT-POSITION-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="STABEL"/>
			<xsd:enumeration value="INSTABLE"/>
			<xsd:enumeration value="BI-STABLE"/>
			<xsd:enumeration value="MULTI-STABLE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SensorActuator::DisplayHW -->
	<xsd:group name="DISPLAY-HW">
		<xsd:annotation>
			<xsd:documentation>
			The Display HW element derives from HW Sensor Actuator and can be connected to a PU via a serial or parallel interface.
For the parallel mode the display can be connected to the data bus and address bus of a PU or to a peripheral.
The most common serial interface for displays are:
- I2C
- SPI
The most common physical interface for high resolution displays are the LVDS interface (Low Voltage Differential Signalling). This interface has three different lines for colours (RGB) and additional lines for control signals.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BACKLIGHT" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines whether the display has a background lighting. This eases the readability of the displays during bad daylight conditions.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="BRIGHTNESS" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the visibility of the display.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CHARACTER-GENERATOR" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			If the display has an in-built character generator.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CHARACTER-SET" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines which character set that can be handled by the display. There is a number of standardised character sets like ISO-8859-1 or Unicode.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="COLOUR" type="AR:DISPLAY-HW-COLOUR-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			If the display can show objects in monochrome, grey scale or in colour.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESOLUTION-RATION" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the ratio of the display resolution in horizontal versus vertical direction (e.g. 16 to 9).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESOLUTION-X" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the number of the smallest graphical elements which can be displayed in horizontal direction.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESOLUTION-Y" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the number of the smallest graphical elements which can be displayed in vertical direction.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESPONSE-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines how long it takes for the display to show a changed element at -20 degree C.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TYPE-OF-CHARACTERS" type="AR:DISPLAY-HW-TYPE-OF-CHARACTERS-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			If the display can present numerical, alpha-numerical, semi-graphical or graphical objects.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="VIEWING-ANGLE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the angle range where the display can be observed.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SensorActuator::DisplayHW -->
	<xsd:complexType name="DISPLAY-HW" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The Display HW element derives from HW Sensor Actuator and can be connected to a PU via a serial or parallel interface.
For the parallel mode the display can be connected to the data bus and address bus of a PU or to a peripheral.
The most common serial interface for displays are:
- I2C
- SPI
The most common physical interface for high resolution displays are the LVDS interface (Low Voltage Differential Signalling). This interface has three different lines for colours (RGB) and additional lines for control signals.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:SENSOR-ACTUATOR-HW"/>
			<xsd:group ref="AR:DISPLAY-HW"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="DISPLAY-HW-COLOUR-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COLOUR"/>
			<xsd:enumeration value="GREY"/>
			<xsd:enumeration value="MONO"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="DISPLAY-HW-TYPE-OF-CHARACTERS-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="NUMERICAL"/>
			<xsd:enumeration value="ALPHA-NUMERISAL"/>
			<xsd:enumeration value="SEMI-GRAPHICAL"/>
			<xsd:enumeration value="GRAPHICAL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SensorActuator::SensorHW -->
	<xsd:group name="SENSOR-HW">
		<xsd:annotation>
			<xsd:documentation>
			HW Element Sensor definition.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SIGNAL-QUALITY" type="AR:SENSOR-HW-SIGNAL-QUALITY-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the quality of the data received from a sensor. Depending on this information later processing on the signal has to be done in HW or SW.
- Raw: The information are transferred without any signal processing from the sensor to the according electronic. Possible spikes and noise is present on the line. In order to use this signal an appropriate signal processing have to be performed.
- Filtered: The information passed some filter mechanism in order to remove noise and spikes from the signal.  The signal can be in a discrete form, At least the limit e.g. the -3dB limit, must be available to the software if this limit is close to the used bandwidth, needed for the planed application.  If more complex filter like bandpasses or notch filter are used the filter characteristic must be modelled and imported for the according SW-Component as well.
- Debounced: The information was already processed by some electronics in order to get a clear and unique representation of the information. Debouncing is a sort of filter which suppress the noises and spikes which are generated by the bouncing when a switch is opened or closed. Debouncing is similar to Filtered, but the input is only represented by digital values instead of analogue values.
Typical debouncing electronics are mono- flops or sampling , plus a majority encoder to represent a more stable signal.
- Coded: The information is filtered and debounced, but furthermore represented in a digital encoded form.
Examples are sensor connected via a serial communication bus like LIN to the ECU.
It must be noted that the complexity of the ECU will have a concomitant effect on the complexity of the corresponding ECU SW abstraction. Generally the more complex the ECU electronics, the more complex the abstract interfaces will be for the user to configure.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SensorActuator::SensorHW -->
	<xsd:complexType name="SENSOR-HW" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			HW Element Sensor definition.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:HW-ELEMENT"/>
			<xsd:group ref="AR:SENSOR-ACTUATOR-HW"/>
			<xsd:group ref="AR:SENSOR-HW"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SENSOR-HW-SIGNAL-QUALITY-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="RAW"/>
			<xsd:enumeration value="FILTERED"/>
			<xsd:enumeration value="DEBOUNCED"/>
			<xsd:enumeration value="CODED"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SensorActuator::SensorActuatorHW -->
	<xsd:group name="SENSOR-ACTUATOR-HW">
		<xsd:annotation>
			<xsd:documentation>
			The common attributes for sensors and actuators.
The sensor and actuators can be connected via a Peripheral HW Port, a Communication HW Port or a Power Driver HW Port.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACCURACY" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the error in the representation of the Technical Signal in the data format
This applies only if the Technical Signal is encoded before it is transferred to the ECU Electronics (e.g. via Communication Transceiver HW Port).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CYCLE-TIME" type="AR:TIME-RANGE" minOccurs="0"/>
			<xsd:element name="RESOLUTION" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the granularity of the representation of the Technical Signal in the data format.
This applies only if the Technical Signal is encoded before it is transferred to the ECU Electronics (e.g. via Communication Transceiver HW Port).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TYPE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines the general type of the sensor/actuator type is a most common naming for a sensor/actuator and is an open list and is not restricted to the following items. Several sets of types exist. Type is mandatory for the usage of the template
- Sensor: Temperature, Pressure, Distance, Hall
- Actuator: DC Motor, Valve, Relay, Display
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="SENSOR-ACTUATOR-HW--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ACTUATOR-HW"/>
			<xsd:enumeration value="DISPLAY-HW"/>
			<xsd:enumeration value="SENSOR-HW"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Characteristic::CalprmElementPrototype -->
	<xsd:complexType name="CALPRM-ELEMENT-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			In the context of a component there is no typed re-use of CalprmElementPrototype entities
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="CALPRM-ELEMENT-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CALPRM-ELEMENT-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Characteristic::CalprmAccess -->
	<xsd:group name="CALPRM-ACCESS">
		<xsd:sequence>
			<xsd:element name="CALPRM-ELEMENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CALPRM-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Characteristic::CalprmAccess -->
	<xsd:complexType name="CALPRM-ACCESS" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:CALPRM-ACCESS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Characteristic::ArCalprmRef -->
	<xsd:group name="AR-CALPRM-REF">
		<xsd:sequence>
			<xsd:element name="AR-CALPRM-IREF" type="AR:AR-CALPRM-REF--CALPRM-ELEMENT-PROTOTYPE-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Characteristic::ArCalprmRef -->
	<xsd:complexType name="AR-CALPRM-REF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:AR-CALPRM-REF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Characteristic::CalprmInterface -->
	<xsd:group name="CALPRM-INTERFACE">
		<xsd:sequence>
			<xsd:element name="CALPRM-ELEMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CALPRM-ELEMENT-PROTOTYPE" type="AR:CALPRM-ELEMENT-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Characteristic::CalprmInterface -->
	<xsd:complexType name="CALPRM-INTERFACE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PORT-INTERFACE"/>
			<xsd:group ref="AR:CALPRM-INTERFACE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ArCalprmRef_CalprmElementPrototype -->
	<xsd:group name="AR-CALPRM-REF--CALPRM-ELEMENT-PROTOTYPE-IREF">
		<xsd:sequence>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CALPRM-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CALPRM-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ArCalprmRef_CalprmElementPrototype -->
	<xsd:complexType name="AR-CALPRM-REF--CALPRM-ELEMENT-PROTOTYPE-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:AR-CALPRM-REF--CALPRM-ELEMENT-PROTOTYPE-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataDefProperties::SwArraysize -->
	<xsd:group name="SW-ARRAYSIZE">
		<xsd:annotation>
			<xsd:documentation>
			The existence of &lt;swArraysize&gt; turns the parent element into a multidimensional object. It is then possible to create arrays of variables, parameters etc. &lt;swArraysize&gt; should ** to imitate stereotypes such as curves or maps since these structures are stored in the DTD itself as own elements, refer to &lt;swCalprmAxisSet&gt; for a &lt;swCalprm&gt;. Apart from that any array can be created.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-ARRAYSIZE_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice>
			<xsd:choice minOccurs="0" maxOccurs="unbounded">
				<xsd:element name="VF" type="AR:VF" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element name="V" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
					<xsd:annotation>
						<xsd:documentation>
			Use &lt;v&gt; to enter a numerical value.
		</xsd:documentation>
						<xsd:appinfo source="tags">
		   			xml.sequenceOffset="30";msr.id="SW-ARRAYSIZE_TYPE__V"
		  	 </xsd:appinfo>
					</xsd:annotation>
				</xsd:element>
			</xsd:choice>
		</xsd:choice>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwArraysize -->
	<xsd:complexType name="SW-ARRAYSIZE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The existence of &lt;swArraysize&gt; turns the parent element into a multidimensional object. It is then possible to create arrays of variables, parameters etc. &lt;swArraysize&gt; should ** to imitate stereotypes such as curves or maps since these structures are stored in the DTD itself as own elements, refer to &lt;swCalprmAxisSet&gt; for a &lt;swCalprm&gt;. Apart from that any array can be created.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-ARRAYSIZE_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded">
			<xsd:group ref="AR:SW-ARRAYSIZE"/>
		</xsd:choice>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataDefProperties::SwBitRepresentation -->
	<xsd:group name="SW-BIT-REPRESENTATION">
		<xsd:annotation>
			<xsd:documentation>
			Description of the structure of a bit variable: comprises of the &lt;bitPosition&gt; in a memory object (e.g. &lt;swHostVariable&gt;, which stands parallel to &lt;swBitRepresentation&gt;) and the &lt;numberOfBits&gt; . In this way, interrelated memory areas can be described. Non-related memory areas are not supported.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-BIT-REPRESENTATION_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BIT-POSITION" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element is used by a Variable that actually is a part of an other Variable called Host Variable. The BIT-POSITION points out the starting point of the Variable in the Host Variable.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-BIT-REPRESENTATION_TYPE__BIT-POSITION";msr.tbdString="true";xml.sequenceOffset="20"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NUMBER-OF-BITS" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of bits of a bit variable (described by &lt;swBitRepresentation&gt;), calculation based on the position specified by the parallel element &lt;bitPosition&gt; .
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-BIT-REPRESENTATION_TYPE__NUMBER-OF-BITS";msr.tbdString="true";xml.sequenceOffset="30"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwBitRepresentation -->
	<xsd:complexType name="SW-BIT-REPRESENTATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Description of the structure of a bit variable: comprises of the &lt;bitPosition&gt; in a memory object (e.g. &lt;swHostVariable&gt;, which stands parallel to &lt;swBitRepresentation&gt;) and the &lt;numberOfBits&gt; . In this way, interrelated memory areas can be described. Non-related memory areas are not supported.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-BIT-REPRESENTATION_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-BIT-REPRESENTATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-CALIBRATION-ACCESS-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="READ-ONLY"/>
			<xsd:enumeration value="NOT-ACCESSIBLE"/>
			<xsd:enumeration value="READ-WRITE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class DataDefProperties::SwComparisonVariables -->
	<xsd:group name="SW-COMPARISON-VARIABLES">
		<xsd:annotation>
			<xsd:documentation>
			These variables can be used to display the value of a variable on the value axis of a calibration parameter (characteristic), that is currently displayed in the MCD-System. The purpose is to compare the appropriate result from the calibration parameter in question, with a value being calculated or taken from a sensor (the comparison variable).

The sole purpose of this comparison-variable is to serve the calibration process.

Screen representation of comparison variable
     Vs |              |
                        |              |
                        |              |
                     V _|______________|______________
                        |         /----|------
                        |  /-----/     |
                        | /            |
                        |/             |
                        |--------------|--------------
                                       tx          tmot
                
                        tx: akt. Temperatur
                        V:  akt. Geschwindigkeit eingeblendet im MCD-System
                            zu Vergleichszwecken: SW-COMPARISON-VARIABLE
                        Vs: Geschwindigkeitsschwelle über Temperatur
                        tmot: Motortemperatur
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-COMPARISON-VARIABLES_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:choice minOccurs="0" maxOccurs="unbounded">
				<xsd:group ref="AR:DATA-PROTOTYPE-REF"/>
				<xsd:group ref="AR:RECORD-ELEMENT-REF"/>
				<xsd:group ref="AR:SW-VARIABLE-REF-MSR"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwComparisonVariables -->
	<xsd:complexType name="SW-COMPARISON-VARIABLES" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			These variables can be used to display the value of a variable on the value axis of a calibration parameter (characteristic), that is currently displayed in the MCD-System. The purpose is to compare the appropriate result from the calibration parameter in question, with a value being calculated or taken from a sensor (the comparison variable).

The sole purpose of this comparison-variable is to serve the calibration process.

Screen representation of comparison variable
     Vs |              |
                        |              |
                        |              |
                     V _|______________|______________
                        |         /----|------
                        |  /-----/     |
                        | /            |
                        |/             |
                        |--------------|--------------
                                       tx          tmot
                
                        tx: akt. Temperatur
                        V:  akt. Geschwindigkeit eingeblendet im MCD-System
                            zu Vergleichszwecken: SW-COMPARISON-VARIABLE
                        Vs: Geschwindigkeitsschwelle über Temperatur
                        tmot: Motortemperatur
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-COMPARISON-VARIABLES_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-COMPARISON-VARIABLES"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataDefProperties::SwGenericAxisParamValue -->
	<xsd:group name="SW-GENERIC-AXIS-PARAM-VALUE">
		<xsd:choice>
			<xsd:choice minOccurs="0" maxOccurs="unbounded">
				<xsd:element name="VF" type="AR:VF" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element name="V" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
					<xsd:annotation>
						<xsd:documentation>
			Use &lt;v&gt; to enter a numerical value.
		</xsd:documentation>
						<xsd:appinfo source="tags">
		   			xml.sequenceOffset="50";msr.id="SW-GENERIC-AXIS-PARAM-VALUE__V"
		  	 </xsd:appinfo>
					</xsd:annotation>
				</xsd:element>
			</xsd:choice>
		</xsd:choice>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwGenericAxisParamValue -->
	<xsd:complexType name="SW-GENERIC-AXIS-PARAM-VALUE" abstract="false" mixed="false">
		<xsd:choice minOccurs="0" maxOccurs="unbounded">
			<xsd:group ref="AR:SW-GENERIC-AXIS-PARAM-VALUE"/>
		</xsd:choice>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataDefProperties::SwDataDependency -->
	<xsd:group name="SW-DATA-DEPENDENCY">
		<xsd:annotation>
			<xsd:documentation>
			This element describes the interdependencies of variables and parameters. These can be used for example, to treat virtual parameters.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-DATA-DEPENDENCY_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-DATA-DEPENDENCY-FORMULA" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element describes the formula with which the dependencies between the participating objects are defined. The formulae are texts which formulate first order arithmetical expressions.

The following syntax is valid:

numeric_expression ::= ( &quot;-&quot;expression ) | ( expression ( &quot;+&quot; | &quot;-&quot; | &quot;*&quot; | &quot;/&quot; | &quot;^&quot;) expression )
                expression ::= ( number | variable | numeric_expression | ( &quot;(&quot; expression &quot;)&quot; ) | sinus_statement | cosinus_statement | sqrt_statement ) | expression {white-space}
                sinus_statement ::= &quot;sin&quot; &quot;(&quot; expression &quot;)&quot;
                cosinus_statement ::= &quot;cos&quot; &quot;(&quot; expression &quot;)&quot;
                sqrt_statement ::= &quot;sqrt&quot; &quot;(&quot; expression &quot;)&quot;
                number ::= integer_literal | float_literal
                variable ::= Any valid Object in question
                integer_literal ::= ( &quot;1..9&quot; { &quot;0..9&quot; } ) | ( &quot;0&quot; &quot;x&quot; &quot;0..9a..f&quot; { &quot;0..9a..f&quot; } )
                float_literal ::= ( decimal_digits &quot;.&quot;  decimal_digits   exponent_part  ) | ( &quot;.&quot; decimal_digits  exponent_part  ) | ( decimal_digits  exponent_part  )
                decimal_digits ::= &quot;0..9&quot; { &quot;0..9&quot; }
                exponent_part ::= &quot;e&quot;  &quot;+&quot; | &quot;-&quot;  decimal_digits
                white-space ::= tabulator | blank | newline | carriage_return | {tabulator | blank | newline | carriage_return }
                tabulator ::= \t
                blank ::= &quot; &quot;
                newline ::= \n
                carriage_return ::= \c
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-DATA-DEPENDENCY_TYPE__SW-DATA-DEPENDENCY-FORMULA";msr.tbdString="true";xml.sequenceOffset="30"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-DATA-DEPENDENCY-ARGS" type="AR:SW-DATA-DEPENDENCY-ARGS" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwDataDependency -->
	<xsd:complexType name="SW-DATA-DEPENDENCY" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element describes the interdependencies of variables and parameters. These can be used for example, to treat virtual parameters.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-DATA-DEPENDENCY_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-DATA-DEPENDENCY"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataDefProperties::SwDataDependencyArgs -->
	<xsd:group name="SW-DATA-DEPENDENCY-ARGS">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the elements used in a &lt;swDataDependency&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-DATA-DEPENDENCY-ARGS_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice>
			<xsd:choice minOccurs="0" maxOccurs="unbounded">
				<xsd:element name="SW-CALPRM" minOccurs="0" maxOccurs="unbounded">
					<xsd:complexType>
						<xsd:choice minOccurs="0">
							<xsd:element name="AR-CALPRM-REF" type="AR:AR-CALPRM-REF"/>
							<xsd:element name="SW-CALPRM-REF-PROXY" type="AR:SW-CALPRM-REF-PROXY"/>
							<xsd:element name="SW-CALPRM-REF" type="AR:SW-CALPRM-REF"/>
						</xsd:choice>
					</xsd:complexType>
				</xsd:element>
				<xsd:element name="SW-VARIABLE-REF" minOccurs="0" maxOccurs="unbounded">
					<xsd:complexType>
						<xsd:choice minOccurs="0">
							<xsd:element name="DATA-PROTOTYPE-REF" type="AR:DATA-PROTOTYPE-REF"/>
							<xsd:element name="RECORD-ELEMENT-REF" type="AR:RECORD-ELEMENT-REF"/>
							<xsd:element name="SW-VARIABLE-REF-MSR" type="AR:SW-VARIABLE-REF-MSR"/>
						</xsd:choice>
					</xsd:complexType>
				</xsd:element>
			</xsd:choice>
		</xsd:choice>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwDataDependencyArgs -->
	<xsd:complexType name="SW-DATA-DEPENDENCY-ARGS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the elements used in a &lt;swDataDependency&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-DATA-DEPENDENCY-ARGS_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded">
			<xsd:group ref="AR:SW-DATA-DEPENDENCY-ARGS"/>
		</xsd:choice>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-IMPL-POLICY-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="STANDARD"/>
			<xsd:enumeration value="MEASUREMENT-POINT"/>
			<xsd:enumeration value="MESSAGE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class DataDefProperties::SwPointer -->
	<xsd:group name="SW-POINTER">
		<xsd:annotation>
			<xsd:documentation>
			This element indicates, that the data object (which is specified by the parent element) is a reference to another data object. The properties of the referred data object are described in the &lt;swDataDefProps&gt; contained in the &lt;swPointer&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-POINTER_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-DATA-DEF-PROPS" type="AR:SW-DATA-DEF-PROPS" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwPointer -->
	<xsd:complexType name="SW-POINTER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element indicates, that the data object (which is specified by the parent element) is a reference to another data object. The properties of the referred data object are described in the &lt;swDataDefProps&gt; contained in the &lt;swPointer&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-POINTER_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-POINTER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataDefProperties::SwSemaphore -->
	<xsd:group name="SW-SEMAPHORE">
		<xsd:annotation>
			<xsd:documentation>
			This element denotes a variable which servers as a semaphore variable for a particular ressource which is specified in the surrounding &lt;swDataDefProps&gt;
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-SEMAPHORE_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:DATA-PROTOTYPE-REF"/>
				<xsd:group ref="AR:RECORD-ELEMENT-REF"/>
				<xsd:group ref="AR:SW-VARIABLE-REF-MSR"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwSemaphore -->
	<xsd:complexType name="SW-SEMAPHORE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element denotes a variable which servers as a semaphore variable for a particular ressource which is specified in the surrounding &lt;swDataDefProps&gt;
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-SEMAPHORE_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-SEMAPHORE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataDefProperties::SwTextProps -->
	<xsd:group name="SW-TEXT-PROPS">
		<xsd:annotation>
			<xsd:documentation>
			The properties specific for a textual calibration parameter / variable.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-TEXT-PROPS_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-MAX-TEXT-SIZE" type="AR:VF" minOccurs="0"/>
			<xsd:element name="SW-FILL-CHARACTER" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Filler character for text parameter to pad up to the maximum length &lt;SwCalprmMaxTextSize&gt; in the parent element &lt;SwCalprmText&gt; .
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-TEXT-PROPS_TYPE__SW-FILL-CHARACTER";msr.tbdString="true";xml.sequenceOffset="40"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwTextProps -->
	<xsd:complexType name="SW-TEXT-PROPS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The properties specific for a textual calibration parameter / variable.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-TEXT-PROPS_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-TEXT-PROPS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-VARIABLE-ACCESS-IMPL-POLICY-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="OPTIMIZED"/>
			<xsd:enumeration value="SELECTABLE"/>
			<xsd:enumeration value="DIRECT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class DataDefProperties::SwVariableRef -->
	<xsd:group name="SW-VARIABLE-REF">
		<xsd:annotation>
			<xsd:documentation>
			This element references &lt;swVariable&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-VARIABLE-REF_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:DATA-PROTOTYPE-REF"/>
				<xsd:group ref="AR:RECORD-ELEMENT-REF"/>
				<xsd:group ref="AR:SW-VARIABLE-REF-MSR"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwVariableRef -->
	<xsd:complexType name="SW-VARIABLE-REF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element references &lt;swVariable&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-VARIABLE-REF_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-VARIABLE-REF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataDefProperties::SwDataDefProps -->
	<xsd:group name="SW-DATA-DEF-PROPS">
		<xsd:annotation>
			<xsd:documentation>
			This element describes all of the distinguishing characteristics of a data object (variable or parameter). &lt;swDataDefProps&gt; is used in every case, where characteristics of data objects must be given.

It is inevitable that not all of the inputs are useful all of the time. Hence, the process definition or the DCI has the task of implementing limitations.

The &lt;swDataDefProps&gt; describe the characteristics of all axes:

* The characteristics of the argument axes (abscissas) are described in &lt;swCalprmAxisSet&gt; .

* The characteristics of the value axis are described directly in &lt;swDataDefProps&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-DATA-DEF-PROPS_TYPE";msr.isCond="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="INVALID-VALUE" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0">
						<xsd:element name="BOOLEAN-LITERAL" type="AR:BOOLEAN-LITERAL"/>
						<xsd:element name="CHAR-LITERAL" type="AR:CHAR-LITERAL"/>
						<xsd:element name="INTEGER-LITERAL" type="AR:INTEGER-LITERAL"/>
						<xsd:element name="OPAQUE-LITERAL" type="AR:OPAQUE-LITERAL"/>
						<xsd:element name="REAL-LITERAL" type="AR:REAL-LITERAL"/>
						<xsd:element name="STRING-LITERAL" type="AR:STRING-LITERAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-ADDR-METHOD-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-ADDR-METHOD--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="BASE-TYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-BASE-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-BIT-REPRESENTATION" type="AR:SW-BIT-REPRESENTATION" minOccurs="0"/>
			<xsd:element name="SW-CALIBRATION-ACCESS" type="AR:SW-CALIBRATION-ACCESS-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describes the applicability of parameters and variables. Valid values are:

* NOT-ACCESSIBLE : The element will not appear in an ASAP file.

* READ-ONLY : The element will only appear as read-only in an ASAP file.

* READ-WRITE : Both read and write access.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-DATA-DEF-PROPS_TYPE__SW-CALIBRATION-ACCESS";msr.tbdString="true";xml.sequenceOffset="70"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-VALUE-BLOCK-SIZE" type="AR:SW-ARRAYSIZE" minOccurs="0"/>
			<xsd:element name="SW-CALPRM-AXIS-SET" type="AR:SW-CALPRM-AXIS-SET" minOccurs="0"/>
			<xsd:element name="SW-TEXT-PROPS" type="AR:SW-TEXT-PROPS" minOccurs="0"/>
			<xsd:element name="SW-CODE-SYNTAX-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-CODE-SYNTAX--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPU-METHOD-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPU-METHOD--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-CONSTR-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-CONSTR--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-DATA-DEPENDENCY" type="AR:SW-DATA-DEPENDENCY" minOccurs="0"/>
			<xsd:element name="SW-HOST-VARIABLE" type="AR:SW-VARIABLE-REF" minOccurs="0"/>
			<xsd:element name="SW-IMPL-POLICY" type="AR:SW-IMPL-POLICY-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			&lt;swImplPolicy&gt; enables the specification of an implementation strategy. In this way, the direction of the implementation to come, can be specified in advance in an earlier phase. The contents of the element comprise of a key word which is to be declared in the process. Examples of possible values are

* MEMORY_OPTIMIZED

* CPU-OPTIMIZED

* INPLACE

* SINGLE-INSTANCE

* MULTI-INSTANCE
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-DATA-DEF-PROPS_TYPE__SW-IMPL-POLICY";msr.tbdString="true";xml.sequenceOffset="230"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-POINTER" type="AR:SW-POINTER" minOccurs="0"/>
			<xsd:element name="SW-RECORD-LAYOUT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-RECORD-LAYOUT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="UNIT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:UNIT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-VARIABLE-ACCESS-IMPL-POLICY" type="AR:SW-VARIABLE-ACCESS-IMPL-POLICY-ENUM" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataDefProperties::SwDataDefProps -->
	<xsd:complexType name="SW-DATA-DEF-PROPS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element describes all of the distinguishing characteristics of a data object (variable or parameter). &lt;swDataDefProps&gt; is used in every case, where characteristics of data objects must be given.

It is inevitable that not all of the inputs are useful all of the time. Hence, the process definition or the DCI has the task of implementing limitations.

The &lt;swDataDefProps&gt; describe the characteristics of all axes:

* The characteristics of the argument axes (abscissas) are described in &lt;swCalprmAxisSet&gt; .

* The characteristics of the value axis are described directly in &lt;swDataDefProps&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-DATA-DEF-PROPS_TYPE";msr.isCond="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-DATA-DEF-PROPS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DatadictionaryProxies::swCalprmRef -->
	<xsd:group name="SW-CALPRM-REF">
		<xsd:annotation>
			<xsd:documentation>
			Through this element, a &lt;swCalprm&gt; is referenced.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-CALPRM-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-CALPRM--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DatadictionaryProxies::swCalprmRef -->
	<xsd:complexType name="SW-CALPRM-REF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Through this element, a &lt;swCalprm&gt; is referenced.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-CALPRM-REF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class DatadictionaryProxies::SwCalprmRefProxy -->
	<xsd:complexType name="SW-CALPRM-REF-PROXY" abstract="false" mixed="false">
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DatadictionaryProxies::SwVariableRefMsr -->
	<xsd:group name="SW-VARIABLE-REF-MSR">
		<xsd:sequence>
			<xsd:element name="SW-VARIABLE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-VARIABLE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DatadictionaryProxies::SwVariableRefMsr -->
	<xsd:complexType name="SW-VARIABLE-REF-MSR" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SW-VARIABLE-REF-MSR"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class CalibrationParameter::SwCalprmAxis -->
	<xsd:group name="SW-CALPRM-AXIS">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies an individual input parameter axis (abscissa). The following belongs to this:

* Which axis is involved ( &lt;swAxisIndex&gt; )

* Whether the axis is integrated ( &lt;swAxisIndividual&gt;) or whether it is adopted from another parameter ( &lt;swAxisGrouped&gt; ).

* Whether the axis can be applicated ( &lt;swCalibrationAccess&gt; ).

* Which display format should be used for the axis ( &lt;SW-DISPLAY-FORMAT&gt; ).

* Which base type should be used for the axis ( &lt;SW-BASE-TYPE-REF&gt; ).
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-AXIS-INDEX" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			&lt;swAxisIndex&gt; describes the index referring to the axis currently described, for which the contents is specified. The index satisfies the following convention:

: 
: 
: 
:
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-CALPRM-AXIS_TYPE__SW-AXIS-INDEX";msr.tbdString="true";xml.sequenceOffset="20"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CATEGORY" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element assigns a category to the parent element. The category can be used by a semantic checker in post-processes to ensure that the parent object is defined correctly i.e. has the right number of elements for example.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-CALPRM-AXIS_TYPE__CATEGORY";msr.tbdString="true";xml.sequenceOffset="30"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:SW-CALPRM-AXIS-COMMON-AXIS"/>
				<xsd:group ref="AR:SW-CALPRM-AXIS-INDIVIDUAL-AXIS"/>
			</xsd:choice>
			<xsd:element name="SW-CALIBRATION-ACCESS" type="AR:SW-CALIBRATION-ACCESS-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describes the applicability of parameters and variables. 
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-CALPRM-AXIS_TYPE__SW-CALIBRATION-ACCESS";msr.tbdString="true";xml.sequenceOffset="90"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="BASE-TYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-BASE-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CalibrationParameter::SwCalprmAxis -->
	<xsd:complexType name="SW-CALPRM-AXIS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies an individual input parameter axis (abscissa). The following belongs to this:

* Which axis is involved ( &lt;swAxisIndex&gt; )

* Whether the axis is integrated ( &lt;swAxisIndividual&gt;) or whether it is adopted from another parameter ( &lt;swAxisGrouped&gt; ).

* Whether the axis can be applicated ( &lt;swCalibrationAccess&gt; ).

* Which display format should be used for the axis ( &lt;SW-DISPLAY-FORMAT&gt; ).

* Which base type should be used for the axis ( &lt;SW-BASE-TYPE-REF&gt; ).
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-CALPRM-AXIS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class CalibrationParameter::SwCalprmAxisCommonAxis -->
	<xsd:group name="SW-CALPRM-AXIS-COMMON-AXIS">
		<xsd:sequence>
			<xsd:element name="SW-AXIS-GROUPED" type="AR:SW-AXIS-GROUPED" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CalibrationParameter::SwCalprmAxisCommonAxis -->
	<xsd:complexType name="SW-CALPRM-AXIS-COMMON-AXIS" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SW-CALPRM-AXIS-COMMON-AXIS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class CalibrationParameter::SwCalprmAxisIndividualAxis -->
	<xsd:group name="SW-CALPRM-AXIS-INDIVIDUAL-AXIS">
		<xsd:sequence>
			<xsd:element name="SW-AXIS-INDIVIDUAL" type="AR:SW-AXIS-INDIVIDUAL" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CalibrationParameter::SwCalprmAxisIndividualAxis -->
	<xsd:complexType name="SW-CALPRM-AXIS-INDIVIDUAL-AXIS" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SW-CALPRM-AXIS-INDIVIDUAL-AXIS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class CalibrationParameter::SwCalprmAxisSet -->
	<xsd:group name="SW-CALPRM-AXIS-SET">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the input parameter axes (abscissas) of parameters (and variables, if these are used adaptively).
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS-SET_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-CALPRM-AXIS" type="AR:SW-CALPRM-AXIS" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CalibrationParameter::SwCalprmAxisSet -->
	<xsd:complexType name="SW-CALPRM-AXIS-SET" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the input parameter axes (abscissas) of parameters (and variables, if these are used adaptively).
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-CALPRM-AXIS-SET_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-CALPRM-AXIS-SET"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class CalibrationParameter::SwCalprmValueAxisLabels -->
	<xsd:complexType name="SW-CALPRM-VALUE-AXIS-LABELS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element is used to record textual descriptions of axis values and is contained in ASAP1.4, for reasons of backward compatibility.

In new systems, the application should be implemented via conversion formulae.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-CALPRM-VALUE-AXIS-LABELS_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class CalibrationParameter::SwCalprm -->
	<xsd:group name="SW-CALPRM">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the characteristics of calibration parameters in the ECU. Calibration parameters are objects that are not adapted to the run time of the vehicle. Instead, they calibrated to a greater extent in the application phase. Variables are quite the opposite ( &lt;swVariable&gt; s), being objects that are manipulated during the run time of the software.

For the most part, calibration parameters consist of:

* Long and short names ( &lt;longName&gt;, &lt;shortName&gt; )

* Short description ( &lt;desc&gt; )

* Category ( &lt;category&gt; ), describing the basic structure of the parameter

* Field parameter ( &lt;swArraysize&gt; ), in case the parameter an array

* The technical characteristics ( &lt;swDataDefProps&gt;) These are identical to the technical characteristics of variables

* Sub-structures simulated through the integration of &lt;swCalprms&gt; .

* Comments ( &lt;annotations&gt; ), enabling notes to be passed on from one stage to the next, throughout the development process.

* Additional information ( &lt;addInfo&gt;) in verbal form. Here, formal components can also be accommodated when SI -attributes are used.

Allocation of &lt;category&gt;



Value Conforms to ASAP

* Meaning

** Remark

VALUE

* Characteristic value

** This represents a single value.

CURVE_INDIVIDUAL

* Characteristic

** This represents a curve with an embedded axis.

MAP_INDIVIDUAL

* Map

** This represents a map with embedded axes.

CURVE_FIXED

* Fixed characteristic

** This indicates a curve where the axes are calculated by the ECU program. The algorithm is fixed and therefore the axis-points can not be calibrated. The parameters of the algorithm may in some cases be specified by applying &lt;swAxisGeneric&gt; .

MAP_FIXED

* Fixed map

** This indicates a map where the axes are calculated by the ECU program. The algorithm is fixed and therefore the axis-points can not be calibrated. The parameters of the algorithm may in some cases be specified by applying &lt;swAxisGeneric&gt; .

CURVE_GROUPED

* Group characteristic

** This indicates a curve which uses the axis-points of another calibration parameter which is then referred to by &lt;swCalprmRef&gt; in &lt;swAxisGrouped&gt; .

MAP_GROUPED

* Group map

** This indicates a map which uses the axis-points of another calibration parameter which is then referred to by &lt;swCalprmRef&gt; in &lt;swAxisGrouped&gt; .

ASCII

* Characteristic text

** This indicates a parameter in text form (e.g. a message).

STRUCTURE

* Parameter structure

** This indicates a structure of calibration parameters. In this case, an embedded &lt;swCalprm&gt; should exist.

VALUE_BLOCK

* Characteristic values block

** This indicates a homogeneous parameter set which is handled as a block. Unlike structures or arrays, the components of a value block appear in the instance tree within one &lt;swInstance&gt; .

AXIS_VALUES

* Group datapoints

** This indicates the axis points of a calibration parameter, which are referenced in &lt;SW-AXIS-GROUP&gt; by a calibration parameter of the category MAP_GROUPED or CURVE_GROUPED .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-CALPRM_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-ARRAYSIZE" type="AR:SW-ARRAYSIZE" minOccurs="0"/>
			<xsd:element name="SW-DATA-DEF-PROPS" type="AR:SW-DATA-DEF-PROPS" minOccurs="0"/>
			<xsd:element name="SW-CALPRMS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SW-CALPRM" type="AR:SW-CALPRM"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CalibrationParameter::SwCalprm -->
	<xsd:complexType name="SW-CALPRM" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the characteristics of calibration parameters in the ECU. Calibration parameters are objects that are not adapted to the run time of the vehicle. Instead, they calibrated to a greater extent in the application phase. Variables are quite the opposite ( &lt;swVariable&gt; s), being objects that are manipulated during the run time of the software.

For the most part, calibration parameters consist of:

* Long and short names ( &lt;longName&gt;, &lt;shortName&gt; )

* Short description ( &lt;desc&gt; )

* Category ( &lt;category&gt; ), describing the basic structure of the parameter

* Field parameter ( &lt;swArraysize&gt; ), in case the parameter an array

* The technical characteristics ( &lt;swDataDefProps&gt;) These are identical to the technical characteristics of variables

* Sub-structures simulated through the integration of &lt;swCalprms&gt; .

* Comments ( &lt;annotations&gt; ), enabling notes to be passed on from one stage to the next, throughout the development process.

* Additional information ( &lt;addInfo&gt;) in verbal form. Here, formal components can also be accommodated when SI -attributes are used.

Allocation of &lt;category&gt;



Value Conforms to ASAP

* Meaning

** Remark

VALUE

* Characteristic value

** This represents a single value.

CURVE_INDIVIDUAL

* Characteristic

** This represents a curve with an embedded axis.

MAP_INDIVIDUAL

* Map

** This represents a map with embedded axes.

CURVE_FIXED

* Fixed characteristic

** This indicates a curve where the axes are calculated by the ECU program. The algorithm is fixed and therefore the axis-points can not be calibrated. The parameters of the algorithm may in some cases be specified by applying &lt;swAxisGeneric&gt; .

MAP_FIXED

* Fixed map

** This indicates a map where the axes are calculated by the ECU program. The algorithm is fixed and therefore the axis-points can not be calibrated. The parameters of the algorithm may in some cases be specified by applying &lt;swAxisGeneric&gt; .

CURVE_GROUPED

* Group characteristic

** This indicates a curve which uses the axis-points of another calibration parameter which is then referred to by &lt;swCalprmRef&gt; in &lt;swAxisGrouped&gt; .

MAP_GROUPED

* Group map

** This indicates a map which uses the axis-points of another calibration parameter which is then referred to by &lt;swCalprmRef&gt; in &lt;swAxisGrouped&gt; .

ASCII

* Characteristic text

** This indicates a parameter in text form (e.g. a message).

STRUCTURE

* Parameter structure

** This indicates a structure of calibration parameters. In this case, an embedded &lt;swCalprm&gt; should exist.

VALUE_BLOCK

* Characteristic values block

** This indicates a homogeneous parameter set which is handled as a block. Unlike structures or arrays, the components of a value block appear in the instance tree within one &lt;swInstance&gt; .

AXIS_VALUES

* Group datapoints

** This indicates the axis points of a calibration parameter, which are referenced in &lt;SW-AXIS-GROUP&gt; by a calibration parameter of the category MAP_GROUPED or CURVE_GROUPED .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-CALPRM_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SW-CALPRM"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-CALPRM--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SW-CALPRM"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class BaseTypes::BaseType -->
	<xsd:group name="BASE-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			Indicates the basic type how the object (measurement or calibration parameter) is handled within the ECU.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__BASE-TYPE_TYPE";msr.isMaster="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:BASE-TYPE-DIRECT-DEFINITION"/>
				<xsd:group ref="AR:BASE-TYPE-INDIRECT-DEFINITION"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class BaseTypes::BaseTypeAbsSize -->
	<xsd:group name="BASE-TYPE-ABS-SIZE">
		<xsd:sequence>
			<xsd:element name="BASE-TYPE-SIZE" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BaseTypes::BaseTypeAbsSize -->
	<xsd:complexType name="BASE-TYPE-ABS-SIZE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:BASE-TYPE-ABS-SIZE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class BaseTypes::BaseTypeDirectDefinition -->
	<xsd:group name="BASE-TYPE-DIRECT-DEFINITION">
		<xsd:sequence>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:BASE-TYPE-ABS-SIZE"/>
				<xsd:group ref="AR:BASE-TYPE-MAX-SIZE"/>
			</xsd:choice>
			<xsd:element name="BASE-TYPE-ENCODING" type="xsd:string" minOccurs="0"/>
			<xsd:element name="MEM-ALIGNMENT" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			describes the alignment of the memory object in bits
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="BASE-TYPE_directDefinition_TYPE__MEM-ALIGNMENT";msr.tbdString="true";xml.sequenceOffset="100"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="BYTE-ORDER" type="AR:BYTE-ORDER" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BaseTypes::BaseTypeDirectDefinition -->
	<xsd:complexType name="BASE-TYPE-DIRECT-DEFINITION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:BASE-TYPE-DIRECT-DEFINITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class BaseTypes::BaseTypeIndirectDefinition -->
	<xsd:group name="BASE-TYPE-INDIRECT-DEFINITION">
		<xsd:sequence>
			<xsd:element name="BASE-TYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-BASE-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BaseTypes::BaseTypeIndirectDefinition -->
	<xsd:complexType name="BASE-TYPE-INDIRECT-DEFINITION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:BASE-TYPE-INDIRECT-DEFINITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class BaseTypes::BaseTypeMaxSize -->
	<xsd:group name="BASE-TYPE-MAX-SIZE">
		<xsd:sequence>
			<xsd:element name="MAX-BASE-TYPE-SIZE" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BaseTypes::BaseTypeMaxSize -->
	<xsd:complexType name="BASE-TYPE-MAX-SIZE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:BASE-TYPE-MAX-SIZE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class BaseTypes::SwBaseType -->
	<xsd:complexType name="SW-BASE-TYPE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:BASE-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-BASE-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SW-BASE-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ByteOrder::ByteOrder -->
	<xsd:group name="BYTE-ORDER">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the byte order of the parent element. The byte order is defined with the attribute TYPE. Possible values are:

* MOST-SIGNIFICANT-BYTE-FIRST

* MOST-SIGNIFICANT-BYTE-LAST
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="BYTE-ORDER";msr.id="type__BYTE-ORDER_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONTENT" type="AR:BYTE-ORDER-ENUM" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ByteOrder::ByteOrder -->
	<xsd:complexType name="BYTE-ORDER">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the byte order of the parent element. The byte order is defined with the attribute TYPE. Possible values are:

* MOST-SIGNIFICANT-BYTE-FIRST

* MOST-SIGNIFICANT-BYTE-LAST
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="BYTE-ORDER";msr.id="type__BYTE-ORDER_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:simpleContent>
			<xsd:extension base="AR:BYTE-ORDER-ENUM">
				<xsd:attributeGroup ref="AR:AR-OBJECT"/>
			</xsd:extension>
		</xsd:simpleContent>
	</xsd:complexType>
	<!-- element group for class Axis::SwAxisGeneric -->
	<xsd:group name="SW-AXIS-GENERIC">
		<xsd:annotation>
			<xsd:documentation>
			This element defines an axis for the base points calculated in the ECU. The ECU is equipped with a fixed calculation algorithm. Parameters for the algorithm can be stored in the data component of the ECU. The following is valid:

* The algorithm to be used is specified as &lt;swAxisType&gt; in the data dictionary ** (reservation of keyword and specification of parameters). Thus when forming an axis, the algorithm is given through the appropriate reference ( &lt;swAxisTypeRef&gt; ).

* The number of base points to be calculated is defined in &lt;SW-NUMER-OF-AXIS-POINTS&gt;. This element exists to enable the number of axis points to be stored explicitly, although it could also be described as &lt;swGenericAxisParam&gt; .

* The calculated base points can be stored on a physical level in the element &lt;swValuesPhys&gt; , which means that it is not necessary for the required calculation algorithm to be implemented in every MCD system.

* The calculated base points can be stored on a standardized level in the element &lt;swValuesCoded&gt; , which means that it is not necessary for the required calculation algorithm to be implemented in every MCD system.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-AXIS-GENERIC_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-AXIS-TYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-AXIS-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-GENERIC-AXIS-PARAMS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SW-GENERIC-AXIS-PARAM" type="AR:SW-GENERIC-AXIS-PARAM"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Axis::SwAxisGeneric -->
	<xsd:complexType name="SW-AXIS-GENERIC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element defines an axis for the base points calculated in the ECU. The ECU is equipped with a fixed calculation algorithm. Parameters for the algorithm can be stored in the data component of the ECU. The following is valid:

* The algorithm to be used is specified as &lt;swAxisType&gt; in the data dictionary ** (reservation of keyword and specification of parameters). Thus when forming an axis, the algorithm is given through the appropriate reference ( &lt;swAxisTypeRef&gt; ).

* The number of base points to be calculated is defined in &lt;SW-NUMER-OF-AXIS-POINTS&gt;. This element exists to enable the number of axis points to be stored explicitly, although it could also be described as &lt;swGenericAxisParam&gt; .

* The calculated base points can be stored on a physical level in the element &lt;swValuesPhys&gt; , which means that it is not necessary for the required calculation algorithm to be implemented in every MCD system.

* The calculated base points can be stored on a standardized level in the element &lt;swValuesCoded&gt; , which means that it is not necessary for the required calculation algorithm to be implemented in every MCD system.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-AXIS-GENERIC_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-AXIS-GENERIC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Axis::SwAxisType -->
	<xsd:group name="SW-AXIS-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			Reserves names for specific axis calculation strategies. No formal specification is given, due to the fact that it is possible to use arbitrary algorithms for calculating axis-points. Instead, the algorithm is described verbally; the parameters ( &lt;swGenericAxisParamTypes&gt;) are specified formally with respect to their names and constraints. As a result, &lt;swAxisType&gt; mainly reserves appropriate keywords.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-AXIS-TYPE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-GENERIC-AXIS-PARAM-TYPES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SW-GENERIC-AXIS-PARAM-TYPE" type="AR:SW-GENERIC-AXIS-PARAM-TYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Axis::SwAxisType -->
	<xsd:complexType name="SW-AXIS-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Reserves names for specific axis calculation strategies. No formal specification is given, due to the fact that it is possible to use arbitrary algorithms for calculating axis-points. Instead, the algorithm is described verbally; the parameters ( &lt;swGenericAxisParamTypes&gt;) are specified formally with respect to their names and constraints. As a result, &lt;swAxisType&gt; mainly reserves appropriate keywords.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-AXIS-TYPE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SW-AXIS-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-AXIS-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SW-AXIS-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Axis::SwGenericAxisParamType -->
	<xsd:complexType name="SW-GENERIC-AXIS-PARAM-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element describes a generic axis type which contains:

* Plausibility checks can be specified ( &lt;SW-DATA-CONSTR-REF&gt; ).

* Textual description ( &lt;desc&gt; ), as a formal description is not of any use, due to the large variety of possibilities.

* If this parameter contains structures, these can be simulated through the recursive use of &lt;swGenericAxisParamTypes&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-GENERIC-AXIS-PARAM-TYPE_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-GENERIC-AXIS-PARAM-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SW-GENERIC-AXIS-PARAM-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Axis::SwGenericAxisParam -->
	<xsd:group name="SW-GENERIC-AXIS-PARAM">
		<xsd:annotation>
			<xsd:documentation>
			This element describes a specific parameter of a generic axis. For this parameter, the following must be specified:

* The name of the parameter; implemented here through a reference ( &lt;swGenericAxisParamTypeRef&gt;) to a parameter defined on a corresponding axis type. This is contained in the sister element &lt;swAxisTypeRef&gt; of the corresponding &lt;swGenericAxisParams&gt; element.

References can only be made to axis parameters, defined within the referenced axis type.



* The value of the parameter, specified in the element &lt;vf&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-GENERIC-AXIS-PARAM_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-GENERIC-AXIS-PARAM-TYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-GENERIC-AXIS-PARAM-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:SW-GENERIC-AXIS-PARAM-VALUE"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Axis::SwGenericAxisParam -->
	<xsd:complexType name="SW-GENERIC-AXIS-PARAM" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element describes a specific parameter of a generic axis. For this parameter, the following must be specified:

* The name of the parameter; implemented here through a reference ( &lt;swGenericAxisParamTypeRef&gt;) to a parameter defined on a corresponding axis type. This is contained in the sister element &lt;swAxisTypeRef&gt; of the corresponding &lt;swGenericAxisParams&gt; element.

References can only be made to axis parameters, defined within the referenced axis type.



* The value of the parameter, specified in the element &lt;vf&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-GENERIC-AXIS-PARAM_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-GENERIC-AXIS-PARAM"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Axis::SwAxisIndividual -->
	<xsd:group name="SW-AXIS-INDIVIDUAL">
		<xsd:annotation>
			<xsd:documentation>
			This element describes an axis integrated into a parameter (field etc.). The integration makes this individual to each parameter. The so-called group axis represents the counterpart to this. It is conceived as an independent parameter and is referenced by the respective parameters used ( &lt;swCalprmRef&gt; within &lt;swAxisGrouped&gt; ).

The specification of this axis incorporates:

* Possible input variables for the axis ( &lt;swVariableRefs&gt; ).

It is possible to specify more than one variable. Here the following is valid:

* The variable with the highest priority must be given first. It is used in the generation of the code and is also displayed first in the application system.

* All variables referenced must be of the same physical nature. This is usually detected in that the conversion formulae affected refer back to the same ( &lt;SI-UNIT&gt; s).

* This multiple referencing allows a base point distribution for more than one input variable to be used. One example of this are the temperature curves, which can depend both on the induction air temperature and the engine temperature.

These variables can be displayed simultaneously by MCD systems (adjustment systems), enabling operating points to be shown in the curves.

* a conversion formula ( &lt;SW-COMPU-METHOD-REF&gt; )

* a measuring unit ( &lt;SW-UNIT-REF&gt; )

* a bit representation ( &lt;swBitRepresentation&gt; )

* Maximum and minimum number of axis base points ( &lt;swMaxAxisPoints&gt;, &lt;swMinAxisPoints&gt; )

* Plausibility checks ( &lt;SW-DATA-CONSTR-REF&gt; )

* Generic axis characteristics ( &lt;swAxisGeneric&gt; ), in the event that such an axis is involved.

The specifications &lt;swVariableRefs&gt;, &lt;SW-COMPU-METHOD-REF&gt;, &lt;SW-UNIT-REF&gt; can exist in parallel, although physically speaking, only one is practical. This parallelism introduces flexibility into the development process, as axes can be described purely physically, without a conversion formula being available.

The following priority exists:

* &lt;swVariableRefs&gt;

* &lt;SW-COMPU-METHOD-REF&gt;

* &lt;SW-UNIT-REF&gt;
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-AXIS-INDIVIDUAL_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-VARIABLE-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:group ref="AR:DATA-PROTOTYPE-REF"/>
						<xsd:group ref="AR:RECORD-ELEMENT-REF"/>
						<xsd:group ref="AR:SW-VARIABLE-REF-MSR"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPU-METHOD-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPU-METHOD--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="UNIT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:UNIT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-MAX-AXIS-POINTS" type="AR:VF" minOccurs="0"/>
			<xsd:element name="SW-MIN-AXIS-POINTS" type="AR:VF" minOccurs="0"/>
			<xsd:element name="DATA-CONSTR-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-CONSTR--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-AXIS-GENERIC" type="AR:SW-AXIS-GENERIC" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Axis::SwAxisIndividual -->
	<xsd:complexType name="SW-AXIS-INDIVIDUAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element describes an axis integrated into a parameter (field etc.). The integration makes this individual to each parameter. The so-called group axis represents the counterpart to this. It is conceived as an independent parameter and is referenced by the respective parameters used ( &lt;swCalprmRef&gt; within &lt;swAxisGrouped&gt; ).

The specification of this axis incorporates:

* Possible input variables for the axis ( &lt;swVariableRefs&gt; ).

It is possible to specify more than one variable. Here the following is valid:

* The variable with the highest priority must be given first. It is used in the generation of the code and is also displayed first in the application system.

* All variables referenced must be of the same physical nature. This is usually detected in that the conversion formulae affected refer back to the same ( &lt;SI-UNIT&gt; s).

* This multiple referencing allows a base point distribution for more than one input variable to be used. One example of this are the temperature curves, which can depend both on the induction air temperature and the engine temperature.

These variables can be displayed simultaneously by MCD systems (adjustment systems), enabling operating points to be shown in the curves.

* a conversion formula ( &lt;SW-COMPU-METHOD-REF&gt; )

* a measuring unit ( &lt;SW-UNIT-REF&gt; )

* a bit representation ( &lt;swBitRepresentation&gt; )

* Maximum and minimum number of axis base points ( &lt;swMaxAxisPoints&gt;, &lt;swMinAxisPoints&gt; )

* Plausibility checks ( &lt;SW-DATA-CONSTR-REF&gt; )

* Generic axis characteristics ( &lt;swAxisGeneric&gt; ), in the event that such an axis is involved.

The specifications &lt;swVariableRefs&gt;, &lt;SW-COMPU-METHOD-REF&gt;, &lt;SW-UNIT-REF&gt; can exist in parallel, although physically speaking, only one is practical. This parallelism introduces flexibility into the development process, as axes can be described purely physically, without a conversion formula being available.

The following priority exists:

* &lt;swVariableRefs&gt;

* &lt;SW-COMPU-METHOD-REF&gt;

* &lt;SW-UNIT-REF&gt;
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-AXIS-INDIVIDUAL_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-AXIS-INDIVIDUAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Axis::SwAxisGrouped -->
	<xsd:group name="SW-AXIS-GROUPED">
		<xsd:annotation>
			<xsd:documentation>
			A group axis is described in &lt;swAxisGrouped&gt;, as an alternative to &lt;swAxisIndividual&gt; . A group axis is specified using

* the reference ( &lt;swCalprmRef&gt; ) to the parameter from which an axis should be imported, which is then to serve as a group axis

* the index of the axis to be used ( &lt;swAxisIndex&gt;). This index should only be specified if the parameter under &lt;swCalprmRef&gt; contains more than one axis. It is standard practise for the axis index of parameters with more than one axis, to be set to 1, if data has not been assigned to &lt;swAxisIndex&gt; .

* If SW-AXIS-INDEX is equal to 0, the interpolation result of the referenced parameter is used as a base point index. This means that the keyword CURVE_AXIS_REF can be supported.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-AXIS-GROUPED_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:AR-CALPRM-REF"/>
				<xsd:group ref="AR:SW-CALPRM-REF"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Axis::SwAxisGrouped -->
	<xsd:complexType name="SW-AXIS-GROUPED" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A group axis is described in &lt;swAxisGrouped&gt;, as an alternative to &lt;swAxisIndividual&gt; . A group axis is specified using

* the reference ( &lt;swCalprmRef&gt; ) to the parameter from which an axis should be imported, which is then to serve as a group axis

* the index of the axis to be used ( &lt;swAxisIndex&gt;). This index should only be specified if the parameter under &lt;swCalprmRef&gt; contains more than one axis. It is standard practise for the axis index of parameters with more than one axis, to be set to 1, if data has not been assigned to &lt;swAxisIndex&gt; .

* If SW-AXIS-INDEX is equal to 0, the interpolation result of the referenced parameter is used as a base point index. This means that the keyword CURVE_AXIS_REF can be supported.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-AXIS-GROUPED_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-AXIS-GROUPED"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class GlobalConstraints::DataConstrRule -->
	<xsd:group name="DATA-CONSTR-RULE">
		<xsd:sequence>
			<xsd:element name="PHYS-CONSTRS" type="AR:PHYS-CONSTRS" minOccurs="0"/>
			<xsd:element name="INTERNAL-CONSTRS" type="AR:INTERNAL-CONSTRS" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class GlobalConstraints::DataConstrRule -->
	<xsd:complexType name="DATA-CONSTR-RULE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DATA-CONSTR-RULE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class GlobalConstraints::PhysConstrs -->
	<xsd:group name="PHYS-CONSTRS">
		<xsd:sequence>
			<xsd:element name="LOWER-LIMIT" type="AR:LIMIT" minOccurs="0"/>
			<xsd:element name="UPPER-LIMIT" type="AR:LIMIT" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class GlobalConstraints::PhysConstrs -->
	<xsd:complexType name="PHYS-CONSTRS" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:PHYS-CONSTRS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class GlobalConstraints::InternalConstrs -->
	<xsd:group name="INTERNAL-CONSTRS">
		<xsd:sequence>
			<xsd:element name="LOWER-LIMIT" type="AR:LIMIT" minOccurs="0"/>
			<xsd:element name="UPPER-LIMIT" type="AR:LIMIT" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class GlobalConstraints::InternalConstrs -->
	<xsd:complexType name="INTERNAL-CONSTRS" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:INTERNAL-CONSTRS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class GlobalConstraints::ScaleConstr -->
	<xsd:group name="SCALE-CONSTR">
		<xsd:sequence>
			<xsd:element name="SHORT-LABEL" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element specifies a short name for the context element. This label cannot be referenced in the same way as a &lt;shortName&gt; in connection with MSRSW (queries, external applications etc.).
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SCALE-CONSTR_TYPE__SHORT-LABEL";msr.tbdString="true";xml.sequenceOffset="20"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DESC" type="AR:ML-DATA-2" minOccurs="0"/>
			<xsd:element name="LOWER-LIMIT" type="AR:LIMIT" minOccurs="0"/>
			<xsd:element name="UPPER-LIMIT" type="AR:LIMIT" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- attribute group for class GlobalConstraints::ScaleConstr -->
	<xsd:attributeGroup name="SCALE-CONSTR">
		<xsd:attribute name="VALIDITY" type="AR:SCALE-CONSTR-VALIDITY-ENUM"/>
	</xsd:attributeGroup>
	<!-- complex type for class GlobalConstraints::ScaleConstr -->
	<xsd:complexType name="SCALE-CONSTR" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SCALE-CONSTR"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:SCALE-CONSTR"/>
	</xsd:complexType>
	<xsd:simpleType name="SCALE-CONSTR-VALIDITY-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="NOT-DEFINED"/>
			<xsd:enumeration value="NOT-VALID"/>
			<xsd:enumeration value="NOT-AVAILABLE"/>
			<xsd:enumeration value="VALID"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class GlobalConstraints::ScaleConstrs -->
	<xsd:group name="SCALE-CONSTRS">
		<xsd:sequence>
			<xsd:element name="SCALE-CONSTR" type="AR:SCALE-CONSTR" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class GlobalConstraints::ScaleConstrs -->
	<xsd:complexType name="SCALE-CONSTRS" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SCALE-CONSTRS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class GlobalConstraints::SwConstrObjects -->
	<xsd:complexType name="SW-CONSTR-OBJECTS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Parameters or variables can reference plausibility checks. The assignment of data to &lt;swConstrObjects&gt; makes the reverse direction possible.

In this way for example plausibility libraries stored in external files can be latched beneath the previous element &lt;SW-DATA-CONSTRS&gt; -element.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-CONSTR-OBJECTS_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class GlobalConstraints::DataConstr -->
	<xsd:group name="DATA-CONSTR">
		<xsd:annotation>
			<xsd:documentation>
			This class represents the rules how to contraint a particular data object. Such constraints are mainly limits but also monotony requirements. See ASAM-HDO for details.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-DATA-CONSTR";asam.useCase="MDX";msr.id="type__DATA-CONSTR_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-CONSTR-RULES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DATA-CONSTR-RULE" type="AR:DATA-CONSTR-RULE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class GlobalConstraints::DataConstr -->
	<xsd:complexType name="DATA-CONSTR" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This class represents the rules how to contraint a particular data object. Such constraints are mainly limits but also monotony requirements. See ASAM-HDO for details.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-DATA-CONSTR";asam.useCase="MDX";msr.id="type__DATA-CONSTR_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-CONSTR"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="DATA-CONSTR--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="DATA-CONSTR"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Variable::SwVariable -->
	<xsd:group name="SW-VARIABLE">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the characteristics of variables (measurands) in the ECU. Variables are objects that are not adapted to the run time of the vehicle. Calibration parameters are quite the opposite ( &lt;swCalprm&gt; s), being objects that are manipulated during the run time of the software.

For the most part, variables consist of:

* Long and short labels ( &lt;longName&gt;, &lt;shortName&gt; )

* Short description ( &lt;desc&gt; )

* Category ( &lt;category&gt; ), describing the basic structure of the variables

* Field size ( &lt;swArraysize&gt; ), in case the variable is executed as an array

* The technical characteristics ( &lt;swDataDefProps&gt;) These are identical to the technical characteristics of parameters

* Sub-structures simulated through the integration of &lt;swVariables&gt; .

* Comments ( &lt;annotations&gt; ), enabling notes to be passed on from one stage to the next, throughout the development process.

* Additional information ( &lt;addInfo&gt;) in verbal form. Here, formal components can also be accommodated when SI -attributes are used.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-VARIABLE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr SwFeatureVarian SwInstanc SwInstanc SwServiceArg SwServiceRetur SwVariabl"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-ARRAYSIZE" type="AR:SW-ARRAYSIZE" minOccurs="0"/>
			<xsd:element name="SW-DATA-DEF-PROPS" type="AR:SW-DATA-DEF-PROPS" minOccurs="0"/>
			<xsd:element name="SW-VARIABLES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SW-VARIABLE" type="AR:SW-VARIABLE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Variable::SwVariable -->
	<xsd:complexType name="SW-VARIABLE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies the characteristics of variables (measurands) in the ECU. Variables are objects that are not adapted to the run time of the vehicle. Calibration parameters are quite the opposite ( &lt;swCalprm&gt; s), being objects that are manipulated during the run time of the software.

For the most part, variables consist of:

* Long and short labels ( &lt;longName&gt;, &lt;shortName&gt; )

* Short description ( &lt;desc&gt; )

* Category ( &lt;category&gt; ), describing the basic structure of the variables

* Field size ( &lt;swArraysize&gt; ), in case the variable is executed as an array

* The technical characteristics ( &lt;swDataDefProps&gt;) These are identical to the technical characteristics of parameters

* Sub-structures simulated through the integration of &lt;swVariables&gt; .

* Comments ( &lt;annotations&gt; ), enabling notes to be passed on from one stage to the next, throughout the development process.

* Additional information ( &lt;addInfo&gt;) in verbal form. Here, formal components can also be accommodated when SI -attributes are used.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-VARIABLE_TYPE";msr.isNamespace=" TeamMembe SwGenericAxisPara SwCalpr SwFeatureVarian SwInstanc SwInstanc SwServiceArg SwServiceRetur SwVariabl"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SW-VARIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-VARIABLE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SW-VARIABLE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class AuxillaryObjects::SwAddrMethod -->
	<xsd:complexType name="SW-ADDR-METHOD" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An address schematic &lt;swAddrMethod&gt; describes how variables or parameters are addressed in the ECU. Address methods can take the form of direct addressing or indirect addressing using a vector.

The principle role of this element is the declaration of keywords (in the subelement &lt;shortName&gt;) for the address calculation process. The process itself is given a verbal description (in &lt;swAddrMethodDesc&gt;) rather than a formal one. However, a formal reference &lt;swCpuMemSegRef&gt; to the memory segment concerned is issued. In future versions further formal components may be added to this, if required. . This approach was adopted as the number of possible address schematics is relatively small. A complete formal description would create unnecessary work.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-ADDR-METHOD_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-ADDR-METHOD--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SW-ADDR-METHOD"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class AuxillaryObjects::SwRecordLayout -->
	<xsd:group name="SW-RECORD-LAYOUT">
		<xsd:annotation>
			<xsd:documentation>
			Defines how the data objects (variables, calibration parameters etc.) are to be stored in the ECU memory. As an example, this definition specifies the sequence of axis points in the ECU memory. Iterations through axis values are stored within the subelements &lt;swRecordLayoutGroup&gt; . These subelements might be stored embedded.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-RECORD-LAYOUT-GROUP" type="AR:SW-RECORD-LAYOUT-GROUP" minOccurs="0" maxOccurs="unbounded"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class AuxillaryObjects::SwRecordLayout -->
	<xsd:complexType name="SW-RECORD-LAYOUT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Defines how the data objects (variables, calibration parameters etc.) are to be stored in the ECU memory. As an example, this definition specifies the sequence of axis points in the ECU memory. Iterations through axis values are stored within the subelements &lt;swRecordLayoutGroup&gt; . These subelements might be stored embedded.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SW-RECORD-LAYOUT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-RECORD-LAYOUT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SW-RECORD-LAYOUT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class AuxillaryObjects::SwRecordLayoutGroup -->
	<xsd:group name="SW-RECORD-LAYOUT-GROUP">
		<xsd:annotation>
			<xsd:documentation>
			Specifies how a record layout is set up. Using &lt;swRecordLayoutGroup&gt;, it recursively models iterations through axis values. The subelement &lt;swRecordLayoutRef&gt; may reference other &lt;swRecordLayout&gt;s. ** &lt;swRecordLayoutRef&gt;, &lt;swRecordLayoutV&gt; and &lt;swRecordLayoutGroup&gt; ** for the modeled record layout.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT-GROUP_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-RECORD-LAYOUT-GROUP-AXIS" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The contents of this element specifies the axis number within a record layout group &lt;swRecordLayoutGroup&gt;. The sister elements on the right-hand side of the tree next to &lt;swRecordLayoutGroupAxis&gt; refer exactly to this axis number.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-AXIS";msr.tbdString="true";xml.sequenceOffset="30"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-GROUP-INDEX" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element attributes a symbolic name to the iterator of the superimposed record layout group &lt;swRecordLayoutGroup&gt;. This can be referenced as a loop index beneath superimposed or subsequent &lt;swRecordLayoutV&gt; elements.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-INDEX";msr.tbdString="true";xml.sequenceOffset="40"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-GROUP-FROM" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element specifies the iterator index for the point in the axis from which a record layout group &lt;swRecordLayoutGroup&gt; is commenced. Negative values are also possible, i.e. the value -4 counts from the fourth value from the end.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-FROM";msr.tbdString="true";xml.sequenceOffset="60"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-GROUP-TO" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element specifies the iterator index for a point in the axis up to which iteration for a record layout group takes place. Negative values are also possible, i.e. the value -4 counts up to the fourth value from the end.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-TO";msr.tbdString="true";xml.sequenceOffset="70"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-GROUP-STEP" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element specifies the step width for the iterator index, which is used for a record layout group &lt;swRecordLayoutGroup&gt; .
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-GROUP-STEP";msr.tbdString="true";xml.sequenceOffset="80"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-COMPONENT" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element is used to denote the component to which the group in question applies. Thus, the record layout supports structured objects. This secures independence from the sequence of components, because they can be referred to via name.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-GROUP_TYPE__SW-RECORD-LAYOUT-COMPONENT";msr.tbdString="true";xml.sequenceOffset="90"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:SW-RECORD-LAYOUT-GROUP-CONTENT"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class AuxillaryObjects::SwRecordLayoutGroup -->
	<xsd:complexType name="SW-RECORD-LAYOUT-GROUP" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specifies how a record layout is set up. Using &lt;swRecordLayoutGroup&gt;, it recursively models iterations through axis values. The subelement &lt;swRecordLayoutRef&gt; may reference other &lt;swRecordLayout&gt;s. ** &lt;swRecordLayoutRef&gt;, &lt;swRecordLayoutV&gt; and &lt;swRecordLayoutGroup&gt; ** for the modeled record layout.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT-GROUP_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-RECORD-LAYOUT-GROUP"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class AuxillaryObjects::SwRecordLayoutGroupContent -->
	<xsd:group name="SW-RECORD-LAYOUT-GROUP-CONTENT">
		<xsd:choice>
			<xsd:choice minOccurs="0" maxOccurs="unbounded">
				<xsd:element name="SW-RECORD-LAYOUT-REF" minOccurs="0" maxOccurs="unbounded">
					<xsd:complexType>
						<xsd:simpleContent>
							<xsd:extension base="AR:REF">
								<xsd:attribute name="DEST" type="AR:SW-RECORD-LAYOUT--SUBTYPES-ENUM" use="required"/>
							</xsd:extension>
						</xsd:simpleContent>
					</xsd:complexType>
				</xsd:element>
				<xsd:element name="SW-RECORD-LAYOUT-V" type="AR:SW-RECORD-LAYOUT-V" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element name="SW-RECORD-LAYOUT-GROUP" type="AR:SW-RECORD-LAYOUT-GROUP" minOccurs="0" maxOccurs="unbounded"/>
			</xsd:choice>
		</xsd:choice>
	</xsd:group>
	<!-- complex type for class AuxillaryObjects::SwRecordLayoutGroupContent -->
	<xsd:complexType name="SW-RECORD-LAYOUT-GROUP-CONTENT" abstract="false" mixed="false">
		<xsd:choice minOccurs="0" maxOccurs="unbounded">
			<xsd:group ref="AR:SW-RECORD-LAYOUT-GROUP-CONTENT"/>
		</xsd:choice>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class AuxillaryObjects::SwRecordLayoutV -->
	<xsd:group name="SW-RECORD-LAYOUT-V">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies which values are stored for the current &lt;swRecordLayoutGroup&gt;. If no &lt;SW-BASE-TYPE-REF&gt; is present, the &lt;SW-BASE-TYPE&gt; referenced initially in the father element &lt;swRecordLayoutGroup&gt; is valid. The specification of &lt;swRecordLayoutVAxis&gt; gives the axis of the values to be stored in accordance with the current record layout &lt;swRecordLayoutGroup&gt;. In &lt;swRecordLayoutVProp&gt; you are able to specify the type of values that are to be stored, e.g. number or value. Under &lt;SW-RECORD-V-INDEX&gt;, the symbolic values of the axes can be given, for which the value given under &lt;swRecordLayoutVProp&gt; is iterated. These symbolic values relate to the values given in &lt;swRecordLayoutGroupIndex&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT-V_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BASE-TYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-BASE-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-V-AXIS" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element specifies the number of axes with values that are stored in the ECU. Refer to &lt;swRecordLayoutV&gt; for further details.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-V_TYPE__SW-RECORD-LAYOUT-V-AXIS";msr.tbdString="true";xml.sequenceOffset="40"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-V-PROP" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The contents of this element describes the type of values to be stored. The following are permitted:

: 
: 
: 
: 
: 
: 
: 
: 
: 
: 
: 
:
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-V_TYPE__SW-RECORD-LAYOUT-V-PROP";msr.tbdString="true";xml.sequenceOffset="50"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-V-INDEX" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The symbolic value for iteration, or the symbolic values separated by white-spaces, refer to the symbolic values given in &lt;swRecordLayoutGroupIndex&gt; . The iterators are processed from left to right, in such a manner that they symbolize the loop index from the outside to the inside.

An error has occurred if a parameter references a record layout which contains a &lt;swRecordLayoutVIndex&gt; with more components than the number of parameter axes.


		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-V_TYPE__SW-RECORD-LAYOUT-V-INDEX";msr.tbdString="true";xml.sequenceOffset="60"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-V-FIX-VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element specifies the filler character for the current record layout, in the form of hex digits. The element present parallel to this &lt;swRecordLayoutVProp&gt; must therefore have the contents FILL.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="SW-RECORD-LAYOUT-V_TYPE__SW-RECORD-LAYOUT-V-FIX-VALUE";msr.tbdString="true";xml.sequenceOffset="80"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SW-RECORD-LAYOUT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SW-RECORD-LAYOUT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class AuxillaryObjects::SwRecordLayoutV -->
	<xsd:complexType name="SW-RECORD-LAYOUT-V" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element specifies which values are stored for the current &lt;swRecordLayoutGroup&gt;. If no &lt;SW-BASE-TYPE-REF&gt; is present, the &lt;SW-BASE-TYPE&gt; referenced initially in the father element &lt;swRecordLayoutGroup&gt; is valid. The specification of &lt;swRecordLayoutVAxis&gt; gives the axis of the values to be stored in accordance with the current record layout &lt;swRecordLayoutGroup&gt;. In &lt;swRecordLayoutVProp&gt; you are able to specify the type of values that are to be stored, e.g. number or value. Under &lt;SW-RECORD-V-INDEX&gt;, the symbolic values of the axes can be given, for which the value given under &lt;swRecordLayoutVProp&gt; is iterated. These symbolic values relate to the values given in &lt;swRecordLayoutGroupIndex&gt; .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__SW-RECORD-LAYOUT-V_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SW-RECORD-LAYOUT-V"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class AuxillaryObjects::SwRelatedConstrs -->
	<xsd:complexType name="SW-RELATED-CONSTRS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This element describes plausibility rules that go beyond the individual data object. E.g. the overrun shut-off engine speed must not be higher than the maximum engine speed. This plausibility rule is defined in exactly the same way as the contexts and dependencies of virtual characteristic variables and variables.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-RELATED-CONSTRS_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class AuxillaryObjects::SwCodeSyntax -->
	<xsd:complexType name="SW-CODE-SYNTAX" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Code syntax objects fix the representation of the variables and parameters in the program source file. These code syntax objects are defined centrally in &lt;swCodeSyntaxes&gt; and are connected to variables and parameters by means of &lt;SwCodeSyntaxRef&gt; .

The principle role of this element is the declaration of keywords (in the subelement &lt;shortName&gt;) for the code generation procedure. The process itself is given a verbal description (in &lt;swCodeSyntaxDesc&gt; ) rather than a formal one. This approach was adopted as the number of possible code syntax schematics is relatively small. A complete formal description would create unnecessary work.

It is possible however, to store a process-dependent micro syntax in &lt;swCodeSyntaxDesc&gt;, for example within &lt;verbatim&gt; and to label this through a suitable data assignment to the attribute SI .
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__SW-CODE-SYNTAX_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-CODE-SYNTAX--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SW-CODE-SYNTAX"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class MeasurementProperty::DataPrototypeRef -->
	<xsd:group name="DATA-PROTOTYPE-REF">
		<xsd:sequence>
			<xsd:element name="DATA-PROTOTYPE-IREF" type="AR:DATA-PROTOTYPE-REF--DATA-PROTOTYPE-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class MeasurementProperty::DataPrototypeRef -->
	<xsd:complexType name="DATA-PROTOTYPE-REF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DATA-PROTOTYPE-REF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class MeasurementProperty::PerInstanceMemoryVariable -->
	<xsd:group name="PER-INSTANCE-MEMORY-VARIABLE">
		<xsd:sequence>
			<xsd:element name="MEASURABLES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MEASURABLE" type="AR:MEASURABLE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class MeasurementProperty::PerInstanceMemoryVariable -->
	<xsd:complexType name="PER-INSTANCE-MEMORY-VARIABLE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:PER-INSTANCE-MEMORY-VARIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class MeasurementProperty::RecordElementRef -->
	<xsd:group name="RECORD-ELEMENT-REF">
		<xsd:sequence>
			<xsd:element name="RECORD-ELEMENT-IREF" type="AR:RECORD-ELEMENT-REF--RECORD-ELEMENT-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class MeasurementProperty::RecordElementRef -->
	<xsd:complexType name="RECORD-ELEMENT-REF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:RECORD-ELEMENT-REF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class MeasurementProperty::Measurable -->
	<xsd:group name="MEASURABLE">
		<xsd:annotation>
			<xsd:documentation>
			

this class assignes data def properties to particular prototypes. This pattern is necessary, since the interrunnable Variable might be duplicated in case the software component referenced by the InternalBehavior is instantiated more than once on the same ecu.


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-DATA-DEF-PROPS" type="AR:SW-DATA-DEF-PROPS" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class MeasurementProperty::Measurable -->
	<xsd:complexType name="MEASURABLE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			

this class assignes data def properties to particular prototypes. This pattern is necessary, since the interrunnable Variable might be duplicated in case the software component referenced by the InternalBehavior is instantiated more than once on the same ecu.


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:MEASURABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::DataPrototypeRef_DataPrototype -->
	<xsd:group name="DATA-PROTOTYPE-REF--DATA-PROTOTYPE-IREF">
		<xsd:sequence>
			<xsd:element name="COMPOSITE-COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ASSEMBLY-CONNECTOR-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ASSEMBLY-CONNECTOR-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-PROTOTYPE-REF-DATA-PROTOTYPE-IREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-PROTOTYPE-REF--DATA-PROTOTYPE-IREF--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::DataPrototypeRef_DataPrototype -->
	<xsd:complexType name="DATA-PROTOTYPE-REF--DATA-PROTOTYPE-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DATA-PROTOTYPE-REF--DATA-PROTOTYPE-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="DATA-PROTOTYPE-REF--DATA-PROTOTYPE-IREF--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="DATA-PROTOTYPE-REF--DATA-PROTOTYPE-IREF"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class _instanceRef::RecordElementRef_RecordElement -->
	<xsd:group name="RECORD-ELEMENT-REF--RECORD-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="ASSEMBLY-CONNECTOR-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ASSEMBLY-CONNECTOR-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPOSITION-COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RECORD-ELEMENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:RECORD-ELEMENT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::RecordElementRef_RecordElement -->
	<xsd:complexType name="RECORD-ELEMENT-REF--RECORD-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:RECORD-ELEMENT-REF--RECORD-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Composition::AssemblyConnectorPrototype -->
	<xsd:group name="ASSEMBLY-CONNECTOR-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			An assembly connector connects a p-port to an r-port. Unlike a delegation connector, assembly connectors are &quot;real&quot; in the sense that there will be some kind of physical representation (bus, shared memory, ...) they are mapped to.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONNECTOR-COM-SPECS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLIENT-SERVER-CONNECTOR-COM-SPEC" type="AR:CLIENT-SERVER-CONNECTOR-COM-SPEC"/>
						<xsd:element name="SENDER-RECEIVER-CONNECTOR-COM-SPEC" type="AR:SENDER-RECEIVER-CONNECTOR-COM-SPEC"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROVIDER-IREF" type="AR:ASSEMBLY-CONNECTOR-PROTOTYPE--PROVIDER-IREF" minOccurs="0"/>
			<xsd:element name="REQUESTER-IREF" type="AR:ASSEMBLY-CONNECTOR-PROTOTYPE--REQUESTER-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Composition::AssemblyConnectorPrototype -->
	<xsd:complexType name="ASSEMBLY-CONNECTOR-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An assembly connector connects a p-port to an r-port. Unlike a delegation connector, assembly connectors are &quot;real&quot; in the sense that there will be some kind of physical representation (bus, shared memory, ...) they are mapped to.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:CONNECTOR-PROTOTYPE"/>
			<xsd:group ref="AR:ASSEMBLY-CONNECTOR-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ASSEMBLY-CONNECTOR-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ASSEMBLY-CONNECTOR-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Composition::ConnectorPrototype -->
	<xsd:group name="CONNECTOR-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			The base class for connectors between ports. Connectors have to be identifiable to allow references from the system constraint template.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MEASURABLES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MEASURABLE" type="AR:MEASURABLE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class Composition::CompositionType -->
	<xsd:group name="COMPOSITION-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			Aggregating component type to encapsulate and abstract subsystem functionality. Compositions contain instances of the component parts, as well as the connections between them.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMPONENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMPONENT-PROTOTYPE" type="AR:COMPONENT-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CONNECTORS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ASSEMBLY-CONNECTOR-PROTOTYPE" type="AR:ASSEMBLY-CONNECTOR-PROTOTYPE"/>
						<xsd:element name="DELEGATION-CONNECTOR-PROTOTYPE" type="AR:DELEGATION-CONNECTOR-PROTOTYPE"/>
						<xsd:element name="SERVICE-CONNECTOR-PROTOTYPE" type="AR:SERVICE-CONNECTOR-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Composition::CompositionType -->
	<xsd:complexType name="COMPOSITION-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Aggregating component type to encapsulate and abstract subsystem functionality. Compositions contain instances of the component parts, as well as the connections between them.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMPONENT-TYPE"/>
			<xsd:group ref="AR:COMPOSITION-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMPOSITION-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMPOSITION-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Composition::ServiceConnectorPrototype -->
	<xsd:group name="SERVICE-CONNECTOR-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			A ServiceConnectorPrototype connects an application component 
required-service port with the service port provided by the service component. They are only added to the model in ECU Configuration phase for the specific purpose of configuring services within an EcuSwComposition.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="APPLICATION-PORT-IREF" type="AR:SERVICE-CONNECTOR-PROTOTYPE--APPLICATION-PORT-IREF" minOccurs="0"/>
			<xsd:element name="SERVICE-PORT-IREF" type="AR:SERVICE-CONNECTOR-PROTOTYPE--SERVICE-PORT-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Composition::ServiceConnectorPrototype -->
	<xsd:complexType name="SERVICE-CONNECTOR-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A ServiceConnectorPrototype connects an application component 
required-service port with the service port provided by the service component. They are only added to the model in ECU Configuration phase for the specific purpose of configuring services within an EcuSwComposition.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:CONNECTOR-PROTOTYPE"/>
			<xsd:group ref="AR:SERVICE-CONNECTOR-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Composition::DelegationConnectorPrototype -->
	<xsd:group name="DELEGATION-CONNECTOR-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			A delegation connector simply delegates one inner port  (a port of a component that is used inside the composition) to a port of identical type that belongs directly to the composition (a port that is owned by the composition). Just as compositions they are solely for structuring the model and have no physical meanig.

In particular, delegation ports cannot merge or dispatch data.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="INNER-PORT-IREF" type="AR:DELEGATION-CONNECTOR-PROTOTYPE--INNER-PORT-IREF" minOccurs="0"/>
			<xsd:element name="OUTER-PORT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Composition::DelegationConnectorPrototype -->
	<xsd:complexType name="DELEGATION-CONNECTOR-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A delegation connector simply delegates one inner port  (a port of a component that is used inside the composition) to a port of identical type that belongs directly to the composition (a port that is owned by the composition). Just as compositions they are solely for structuring the model and have no physical meanig.

In particular, delegation ports cannot merge or dispatch data.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:CONNECTOR-PROTOTYPE"/>
			<xsd:group ref="AR:DELEGATION-CONNECTOR-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Composition::ComponentPrototype -->
	<xsd:group name="COMPONENT-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			Role of a software component within a composition.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="TYPE-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Composition::ComponentPrototype -->
	<xsd:complexType name="COMPONENT-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Role of a software component within a composition.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMPONENT-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMPONENT-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMPONENT-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class _instanceRef::AssemblyConnectorPrototype_provider -->
	<xsd:group name="ASSEMBLY-CONNECTOR-PROTOTYPE--PROVIDER-IREF">
		<xsd:sequence>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="P-PORT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:P-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::AssemblyConnectorPrototype_provider -->
	<xsd:complexType name="ASSEMBLY-CONNECTOR-PROTOTYPE--PROVIDER-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:ASSEMBLY-CONNECTOR-PROTOTYPE--PROVIDER-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::AssemblyConnectorPrototype_requester -->
	<xsd:group name="ASSEMBLY-CONNECTOR-PROTOTYPE--REQUESTER-IREF">
		<xsd:sequence>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="R-PORT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::AssemblyConnectorPrototype_requester -->
	<xsd:complexType name="ASSEMBLY-CONNECTOR-PROTOTYPE--REQUESTER-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:ASSEMBLY-CONNECTOR-PROTOTYPE--REQUESTER-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::DelegationConnectorPrototype_innerPort -->
	<xsd:group name="DELEGATION-CONNECTOR-PROTOTYPE--INNER-PORT-IREF">
		<xsd:sequence>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::DelegationConnectorPrototype_innerPort -->
	<xsd:complexType name="DELEGATION-CONNECTOR-PROTOTYPE--INNER-PORT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DELEGATION-CONNECTOR-PROTOTYPE--INNER-PORT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ServiceConnectorPrototype_applicationPort -->
	<xsd:group name="SERVICE-CONNECTOR-PROTOTYPE--APPLICATION-PORT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ServiceConnectorPrototype_applicationPort -->
	<xsd:complexType name="SERVICE-CONNECTOR-PROTOTYPE--APPLICATION-PORT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SERVICE-CONNECTOR-PROTOTYPE--APPLICATION-PORT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ServiceConnectorPrototype_servicePort -->
	<xsd:group name="SERVICE-CONNECTOR-PROTOTYPE--SERVICE-PORT-IREF">
		<xsd:sequence>
			<xsd:element name="SERVICE-COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SERVICE-COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ServiceConnectorPrototype_servicePort -->
	<xsd:complexType name="SERVICE-CONNECTOR-PROTOTYPE--SERVICE-PORT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SERVICE-CONNECTOR-PROTOTYPE--SERVICE-PORT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ApplicationAttributes::CalibrationPortAnnotation -->
	<xsd:group name="CALIBRATION-PORT-ANNOTATION">
		<xsd:annotation>
			<xsd:documentation>
			Annotation to a port used for calibration regarding a certain CalprmElement
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CALPRM-ELEMENT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CALPRM-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ApplicationAttributes::CalibrationPortAnnotation -->
	<xsd:complexType name="CALIBRATION-PORT-ANNOTATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Annotation to a port used for calibration regarding a certain CalprmElement
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PORT-ANNOTATION"/>
			<xsd:group ref="AR:CALIBRATION-PORT-ANNOTATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ApplicationAttributes::ComMUserNeeds -->
	<xsd:group name="COM-M-USER-NEEDS">
		<xsd:annotation>
			<xsd:documentation>
			Specifies the SWCs needs on the configuration of the Communication Manager for the &quot;user&quot; associated with this specific Service Port.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MAX-COMM-MODE" type="AR:MAX-COMM-MODE" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			maximum communication mode requested by the ComM user associated with this Service Port
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ApplicationAttributes::ComMUserNeeds -->
	<xsd:complexType name="COM-M-USER-NEEDS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specifies the SWCs needs on the configuration of the Communication Manager for the &quot;user&quot; associated with this specific Service Port.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PORT-ANNOTATION"/>
			<xsd:group ref="AR:COM-M-USER-NEEDS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ApplicationAttributes::ServiceNeeds -->
	<xsd:complexType name="SERVICE-NEEDS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Annotation to a service port of an atomic SWC. It expresses the needs the SWC has on the configuration of the infrastructure (AUTOSAR Service, ECU abstraction or Complex Driver) to which it will be connected via this port.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PORT-ANNOTATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="MAX-COMM-MODE">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="NONE"/>
			<xsd:enumeration value="SILENT"/>
			<xsd:enumeration value="FULL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ApplicationAttributes::ExtAnnotation -->
	<xsd:group name="EXT-ANNOTATION">
		<xsd:annotation>
			<xsd:documentation>
			Allows the specification of port annotations not yet part of the software component template.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="NAME" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Name of the annotation.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Value of the annotation.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ApplicationAttributes::ExtAnnotation -->
	<xsd:complexType name="EXT-ANNOTATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Allows the specification of port annotations not yet part of the software component template.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:EXT-ANNOTATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ApplicationAttributes::FailureMonitoring -->
	<xsd:group name="FAILURE-MONITORING">
		<xsd:annotation>
			<xsd:documentation>
			This attribute is only applicaple in SET operations. If it is enabled, the IoHwAbstraction layer will monitor the result of the opeation and issue an diagnostic signal. This means especially, that an additional client-server port has to be created. Tools can use this information to cross-check whether for each data-element in a SET operation with FailureMonitoring enabled an additional port is created
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MONITORS-FAILURE-IREF" type="AR:FAILURE-MONITORING--MONITORS-FAILURE-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ApplicationAttributes::FailureMonitoring -->
	<xsd:complexType name="FAILURE-MONITORING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This attribute is only applicaple in SET operations. If it is enabled, the IoHwAbstraction layer will monitor the result of the opeation and issue an diagnostic signal. This means especially, that an additional client-server port has to be created. Tools can use this information to cross-check whether for each data-element in a SET operation with FailureMonitoring enabled an additional port is created
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:FAILURE-MONITORING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ApplicationAttributes::IoHwAbstractionServerAnnotation -->
	<xsd:group name="IO-HW-ABSTRACTION-SERVER-ANNOTATION">
		<xsd:annotation>
			<xsd:documentation>
			The ClientServer Port Annotation will only be used from a sensor- or an actuator component while interacting with the IoHwAbstraction layer

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="AGE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			In case of a SET operation, the age will be interpreted as Delay while in a GET operation (input) it specifies the Lifetime of the signal within the IoHwAbstraction Layer

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ARGUMENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ARGUMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="BSW-RANGE-MAX" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies the maximum value of the Range the ECU-Signal is supposed to have
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="BSW-RANGE-MIN" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies the maximum value of the Range the ECU-Signal is supposed to have.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="BSW-RESOLUTION" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This value is determined by an appropriate combination of the range, the unit as well as the data-elements type, i.e. (BswRangeMax-BswRangeMin) / (2^datatypelength - 1)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="FAILURE-MONITORING" type="AR:FAILURE-MONITORING" minOccurs="0"/>
			<xsd:element name="FILTERING-DEBOUNCING" type="AR:IO-HW-ABSTRACTION-SERVER-ANNOTATION-FILTERING-DEBOUNCING-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This attribute is used to indicate what kind of filtering/debouncing has been put to the signal in the IoHwAbstraction layer. 

RAW_DATA means that no modification of the signal has been applied.This is the default value
DEBOUNCE_DATA means that the signal is a mean value
WAIT_TIME_DATE means that the signal is delivered by a GET operation after a certain amount of time

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PULSE-TEST" type="AR:IO-HW-ABSTRACTION-SERVER-ANNOTATION-PULSE-TEST-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This attribute indicates to the connected Actuator Software component whether the data-element can be used to generate pulse test sequences using the IoHwAbstration layer
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="REPORT-FEATURE" type="AR:REPORT-FEATURE" minOccurs="0"/>
			<xsd:element name="UNIT" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			These are either electrical units like Volts (V) or time units like milliseconds (ms). The unit is set according to the ECU Input signal class which is either analogue or modulation
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP" type="AR:WAKE-UP" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ApplicationAttributes::IoHwAbstractionServerAnnotation -->
	<xsd:complexType name="IO-HW-ABSTRACTION-SERVER-ANNOTATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The ClientServer Port Annotation will only be used from a sensor- or an actuator component while interacting with the IoHwAbstraction layer

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PORT-ANNOTATION"/>
			<xsd:group ref="AR:IO-HW-ABSTRACTION-SERVER-ANNOTATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="IO-HW-ABSTRACTION-SERVER-ANNOTATION-PULSE-TEST-ENUM">
		<xsd:restriction base="xsd:string"/>
	</xsd:simpleType>
	<xsd:simpleType name="IO-HW-ABSTRACTION-SERVER-ANNOTATION-FILTERING-DEBOUNCING-ENUM">
		<xsd:restriction base="xsd:string"/>
	</xsd:simpleType>
	<!-- complex type for class ApplicationAttributes::WakeUp -->
	<xsd:complexType name="WAKE-UP" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This attribut indicates wheter the software component reading this value provides dedicated runnables to handle a wake-up call by the IoHwAbstraction layer.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ApplicationAttributes::ReportFeature -->
	<xsd:complexType name="REPORT-FEATURE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This feature is used for input signals only. Each time the level of the associated data-element changes a dedicated  GET operation has to be invoked by the sensor software component, i.e. an appropriate runnable has to be started. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ApplicationAttributes::NVRAMBlockNeeds -->
	<xsd:group name="NVRAM-BLOCK-NEEDS">
		<xsd:annotation>
			<xsd:documentation>
			Specifies the SWCs needs on the configuration of an NVRAM block associated with this specific Service Port.

Note that the block size is not specified here because
- it can be derived from the associated PerInstanceMemory size (implementatiion specific) in case of implicit storage/restauration of the block
- if can be derived from the array size passed via the correponding operations of the Service Interface in case of explicit storage/restauration of the block

The needs for configuring callbacks can also be derived from the existence of additional ports required for that.

The optional association of a RAM mirror block and/or a ROM default block with this NVRAM block is modeled by references from the corresponding elements of the InternalBehavior to this port annotation. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="N-DATA-SETS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			number of data sets to be provided by the NVRAM manager for this block
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="READONLY" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			true: data of this block are write protected for normal operation (but protection can be disabled)
false: no restriction
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RELIABILITY" type="AR:NVRAM-BLOCK-NEEDS-RELIABILITY-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Reliability against data loss on the non-volatile medium.
low: Data loss is uncritical
medium: Data loss should be avoided
high: Data loss is critical 
These requirements give only a relative indication, for example on the required degree of redundancy for storage. They do however not specify by which means (e.g. software or hardware) the reliability is actually achieved.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESISTANT-TO-CHANGED-SW" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines whether a NVRAM block shall be treated resistant to configuration changes (true) or not (false). For details how to handle initialization in the latter case, refer to the NVRAM specification.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESTORE-AT-START" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines whether the associated RAM mirror block shall be implictly restored during startup by the basic SW or not. Only relevant if a RAM mirror block (PerInstanceMemory) is associated with this port.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TRANSACTION-SAFE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			true: If the current write access fails, the last data of this block is still available and stored on the non volatile medium. 
false: If the current write access fails, the current and/or last data of this block may be lost.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WRITE-ONLY-ONCE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines write protection after first write:
true: This block is prevented from being changed/erased or being replaced with the default ROM data after first initialization by the SWC.
false: No such restriction.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WRITING-FREQUENCY" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Provides the amount of updates to this block from the application point of view. It has to be provided in &quot;number of write access per year&quot;.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WRITING-PRIORITY" type="AR:NVRAM-BLOCK-NEEDS-WRITING-PRIORITY-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Requires the priority of writing this block in case of concurrent requests to write other blocks.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ApplicationAttributes::NVRAMBlockNeeds -->
	<xsd:complexType name="NVRAM-BLOCK-NEEDS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specifies the SWCs needs on the configuration of an NVRAM block associated with this specific Service Port.

Note that the block size is not specified here because
- it can be derived from the associated PerInstanceMemory size (implementatiion specific) in case of implicit storage/restauration of the block
- if can be derived from the array size passed via the correponding operations of the Service Interface in case of explicit storage/restauration of the block

The needs for configuring callbacks can also be derived from the existence of additional ports required for that.

The optional association of a RAM mirror block and/or a ROM default block with this NVRAM block is modeled by references from the corresponding elements of the InternalBehavior to this port annotation. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PORT-ANNOTATION"/>
			<xsd:group ref="AR:NVRAM-BLOCK-NEEDS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="NVRAM-BLOCK-NEEDS-RELIABILITY-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="LOW"/>
			<xsd:enumeration value="MEDIUM"/>
			<xsd:enumeration value="HIGH"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="NVRAM-BLOCK-NEEDS-WRITING-PRIORITY-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="LOW"/>
			<xsd:enumeration value="MEDIUM"/>
			<xsd:enumeration value="HIGH"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ApplicationAttributes::ReceiverAnnotation -->
	<xsd:group name="RECEIVER-ANNOTATION">
		<xsd:annotation>
			<xsd:documentation>
			Annotation of a receiver port, specifying properties of data elements that don&apos;t affect communication or generation of the RTE. The given attributes are requirements on the required data.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SIGNAL-AGE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maximum allowed age of the signal since it was originally read by a sensor. This is a requirement specified on the receiver side.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ApplicationAttributes::ReceiverAnnotation -->
	<xsd:complexType name="RECEIVER-ANNOTATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Annotation of a receiver port, specifying properties of data elements that don&apos;t affect communication or generation of the RTE. The given attributes are requirements on the required data.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PORT-ANNOTATION"/>
			<xsd:group ref="AR:SENDER-RECEIVER-ANNOTATION"/>
			<xsd:group ref="AR:RECEIVER-ANNOTATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ApplicationAttributes::SenderReceiverAnnotation -->
	<xsd:group name="SENDER-RECEIVER-ANNOTATION">
		<xsd:annotation>
			<xsd:documentation>
			Annotation of the data elements in a port that realizes a sender/receiver interface.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMPUTED" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Flag whether this data element was not measured directly but instead was calculated from possibly several other measured or calculated values.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="LIMIT-TYPE" type="AR:SENDER-RECEIVER-ANNOTATION-LIMIT-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Indicates whether the data element carries a minimum or maximum value, thereby limiting the current range of another value.
This min or max has not to be mismatched with the min- and max for data-value in a compu-method. For example, this annotation
shows when the result of the calculation performed in a softwar component&apos;s runnable is transmitted to another software component whose runnable will use this value as a limit, e.g. the max.power which can be used by that component, or the current min. slip.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PROCESSING-TYPE" type="AR:SENDER-RECEIVER-ANNOTATION-PROCESSING-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Kind of processing applied to the data element. &quot;raw&quot; specifies that a signal is taken directly from the basic software modules, i.e. from the ECU abstraction layer. It indicates to a developer that the control algorithm in the software has to provide filters. &quot;filtered&quot; indicates that a raw signal has been manipulated by some application software components by using filters. &quot;none&quot; is specified if none of the previous two options apply.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SENDER-RECEIVER-ANNOTATION-DATA-ELEMENT-IREF" type="AR:SENDER-RECEIVER-ANNOTATION--DATA-ELEMENT-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="SENDER-RECEIVER-ANNOTATION-LIMIT-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="NONE"/>
			<xsd:enumeration value="MIN"/>
			<xsd:enumeration value="MAX"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="SENDER-RECEIVER-ANNOTATION-PROCESSING-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="NONE"/>
			<xsd:enumeration value="RAW"/>
			<xsd:enumeration value="FILTERED"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class ApplicationAttributes::SenderAnnotation -->
	<xsd:complexType name="SENDER-ANNOTATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Annotation of a sender port, specifying properties of data elements that don&apos;t affect communication or generation of the RTE. The given attributes are assertions on the provided data.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PORT-ANNOTATION"/>
			<xsd:group ref="AR:SENDER-RECEIVER-ANNOTATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ApplicationAttributes::SupervisedEntityNeeds -->
	<xsd:group name="SUPERVISED-ENTITY-NEEDS">
		<xsd:annotation>
			<xsd:documentation>
			Specifies the SWCs needs on the configuration of the Watchdog Manager for the Supervised Entity (SE) associated with this specific Service Port.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTIVATE-AT-START" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			true/false: supervision activation status of SE shall be enabled/disabled at start
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ENABLE-DEACTIVATION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			true: SWC shall be allowed to deactivate supervision of this SE
false: not
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="EXPECTED-ALIVE-CYCLE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Expected cycle time of alive trigger of this SE (in seconds)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-ALIVE-CYCLE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum cycle time of alive trigger of this SE (in seconds)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-ALIVE-CYCLE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Minimum cycle time of alive trigger of this SE (in seconds)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TOLERATED-FAILED-CYCLES" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of consecutive failed alive cycles for this SE which shall be tolerated until the supervision status of the SE is set to EXPIRED (see WdgM documentation for details). Note that this has to be recalculated w.r.t. the WdgMs own cycle time for ECU configuration.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ApplicationAttributes::SupervisedEntityNeeds -->
	<xsd:complexType name="SUPERVISED-ENTITY-NEEDS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specifies the SWCs needs on the configuration of the Watchdog Manager for the Supervised Entity (SE) associated with this specific Service Port.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PORT-ANNOTATION"/>
			<xsd:group ref="AR:SUPERVISED-ENTITY-NEEDS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ApplicationAttributes::PortAnnotation -->
	<xsd:group name="PORT-ANNOTATION">
		<xsd:annotation>
			<xsd:documentation>
			Base class for annotations of ports. Annotations are attributes that formally specify features and requirements of ports that have currently no influence on the generation of the RTE or the communication in general.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="EXT-ANNOTATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="EXT-ANNOTATION" type="AR:EXT-ANNOTATION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class _instanceRef::FailureMonitoring_monitorsFailure -->
	<xsd:group name="FAILURE-MONITORING--MONITORS-FAILURE-IREF">
		<xsd:sequence>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::FailureMonitoring_monitorsFailure -->
	<xsd:complexType name="FAILURE-MONITORING--MONITORS-FAILURE-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:FAILURE-MONITORING--MONITORS-FAILURE-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SenderReceiverAnnotation_dataElement -->
	<xsd:group name="SENDER-RECEIVER-ANNOTATION--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SenderReceiverAnnotation_dataElement -->
	<xsd:complexType name="SENDER-RECEIVER-ANNOTATION--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-RECEIVER-ANNOTATION--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="DIRECTION-KIND">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="OUT"/>
			<xsd:enumeration value="INOUT"/>
			<xsd:enumeration value="IN"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class PortInterface::ModeDeclarationGroupPrototype -->
	<xsd:group name="MODE-DECLARATION-GROUP-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			The ModePrototype specifies the set of Modes (ModeDeclarationGroup) that is supported by a ComponentType.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="TYPE-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODE-DECLARATION-GROUP--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PortInterface::ModeDeclarationGroupPrototype -->
	<xsd:complexType name="MODE-DECLARATION-GROUP-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The ModePrototype specifies the set of Modes (ModeDeclarationGroup) that is supported by a ComponentType.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:MODE-DECLARATION-GROUP-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="MODE-DECLARATION-GROUP-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MODE-DECLARATION-GROUP-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class PortInterface::OperationPrototype -->
	<xsd:group name="OPERATION-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			An operation declared within the scope of a client/server interface.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ARGUMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ARGUMENT-PROTOTYPE" type="AR:ARGUMENT-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="POSSIBLE-ERROR-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="POSSIBLE-ERROR-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:APPLICATION-ERROR--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PortInterface::OperationPrototype -->
	<xsd:complexType name="OPERATION-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An operation declared within the scope of a client/server interface.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:OPERATION-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="OPERATION-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="OPERATION-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class PortInterface::ArgumentPrototype -->
	<xsd:group name="ARGUMENT-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			An argument of an operation, much like a data element, but also carries direction information and is associated with a particular operation.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DIRECTION" type="AR:DIRECTION-KIND" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PortInterface::ArgumentPrototype -->
	<xsd:complexType name="ARGUMENT-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An argument of an operation, much like a data element, but also carries direction information and is associated with a particular operation.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:ARGUMENT-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ARGUMENT-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ARGUMENT-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class PortInterface::PortInterface -->
	<xsd:group name="PORT-INTERFACE">
		<xsd:annotation>
			<xsd:documentation>
			Abstract base class for an interface that is either provided or required by a ports of a  software component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="IS-SERVICE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This flag is set, if the port interface is to be used for
comunication between an atomic software component and a component of the basic software (namely an AUTOSAR Service, ECU abstraction or Complex Driver) located on the same ECU. Otherwise the flag is not set.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="PORT-INTERFACE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CALPRM-INTERFACE"/>
			<xsd:enumeration value="CLIENT-SERVER-INTERFACE"/>
			<xsd:enumeration value="SENDER-RECEIVER-INTERFACE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class PortInterface::ClientServerInterface -->
	<xsd:group name="CLIENT-SERVER-INTERFACE">
		<xsd:annotation>
			<xsd:documentation>
			A client/server interface declares a number of operations that can be invoked on a server by a client.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OPERATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="OPERATION-PROTOTYPE" type="AR:OPERATION-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="POSSIBLE-ERRORS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="APPLICATION-ERROR" type="AR:APPLICATION-ERROR"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PortInterface::ClientServerInterface -->
	<xsd:complexType name="CLIENT-SERVER-INTERFACE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A client/server interface declares a number of operations that can be invoked on a server by a client.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PORT-INTERFACE"/>
			<xsd:group ref="AR:CLIENT-SERVER-INTERFACE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class PortInterface::SenderReceiverInterface -->
	<xsd:group name="SENDER-RECEIVER-INTERFACE">
		<xsd:annotation>
			<xsd:documentation>
			A sender/receiver interface declares a number of data elements to be sent and received.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DATA-ELEMENT-PROTOTYPE" type="AR:DATA-ELEMENT-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODE-GROUPS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MODE-DECLARATION-GROUP-PROTOTYPE" type="AR:MODE-DECLARATION-GROUP-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PortInterface::SenderReceiverInterface -->
	<xsd:complexType name="SENDER-RECEIVER-INTERFACE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A sender/receiver interface declares a number of data elements to be sent and received.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PORT-INTERFACE"/>
			<xsd:group ref="AR:SENDER-RECEIVER-INTERFACE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class PortInterface::DataElementPrototype -->
	<xsd:group name="DATA-ELEMENT-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			A data element of a sender-receiver interface, supporting signal like communication patterns.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="IS-QUEUED" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			qualifies whether the content of the data element is queued. If it is queued, then the data element has &quot;event&quot; semantics, i.e. data elements are stored in a queue and all data elements are processed in &quot;first in first out&quot; order.
If it is not queued, then the &quot;last is best&quot; semantics applies. Please note: Depending on the read access cycle to the data element some values might not be processed by the receiver. 

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PortInterface::DataElementPrototype -->
	<xsd:complexType name="DATA-ELEMENT-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A data element of a sender-receiver interface, supporting signal like communication patterns.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:DATA-ELEMENT-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="DATA-ELEMENT-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class ModeDeclaration::ModeDeclaration -->
	<xsd:complexType name="MODE-DECLARATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Declaration of one Mode. The name and semantics of a special mode is not defined in the metamodel.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="MODE-DECLARATION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MODE-DECLARATION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="MODE-ACTIVATION-KIND">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ENTRY"/>
			<xsd:enumeration value="EXIT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ModeDeclaration::ModeDisablingDependency -->
	<xsd:group name="MODE-DISABLING-DEPENDENCY">
		<xsd:annotation>
			<xsd:documentation>
			Collection of references to the Modes that disable the RTEEvent
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEPENDENT-ON-MODE-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DEPENDENT-ON-MODE-IREF" type="AR:MODE-DISABLING-DEPENDENCY--DEPENDENT-ON-MODE-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ModeDeclaration::ModeDisablingDependency -->
	<xsd:complexType name="MODE-DISABLING-DEPENDENCY" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Collection of references to the Modes that disable the RTEEvent
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MODE-DISABLING-DEPENDENCY"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ModeDeclaration::ModeDeclarationGroup -->
	<xsd:group name="MODE-DECLARATION-GROUP">
		<xsd:annotation>
			<xsd:documentation>
			A collection of Mode Declarations.
What the actual modes are and how they are named is covered by different WPs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="INITIAL-MODE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODE-DECLARATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODE-DECLARATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MODE-DECLARATION" type="AR:MODE-DECLARATION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ModeDeclaration::ModeDeclarationGroup -->
	<xsd:complexType name="MODE-DECLARATION-GROUP" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A collection of Mode Declarations.
What the actual modes are and how they are named is covered by different WPs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:MODE-DECLARATION-GROUP"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="MODE-DECLARATION-GROUP--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MODE-DECLARATION-GROUP"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class _instanceRef::ModeDisablingDependency_dependentOnMode -->
	<xsd:group name="MODE-DISABLING-DEPENDENCY--DEPENDENT-ON-MODE-IREF">
		<xsd:sequence>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODE-DECLARATION-GROUP-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODE-DECLARATION-GROUP-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODE-DECLARATION-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODE-DECLARATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ModeDisablingDependency_dependentOnMode -->
	<xsd:complexType name="MODE-DISABLING-DEPENDENCY--DEPENDENT-ON-MODE-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:MODE-DISABLING-DEPENDENCY--DEPENDENT-ON-MODE-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="HANDLE-INVALID-TYPE">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="KEEP"/>
			<xsd:enumeration value="REPLACE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::ModeSwitchComSpec -->
	<xsd:group name="MODE-SWITCH-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes for both sender /server port (P-Port and sender-receiver interface). (0=unqueued)
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MODE-SWITCHED-ACK" type="AR:MODE-SWITCHED-ACK-REQUEST" minOccurs="0"/>
			<xsd:element name="QUEUE-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Length of call queue on the server side. The queue is implemented by the RTE.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::ModeSwitchComSpec -->
	<xsd:complexType name="MODE-SWITCH-COM-SPEC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes for both sender /server port (P-Port and sender-receiver interface). (0=unqueued)
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MODE-SWITCH-COM-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::ModeSwitchedAckRequest -->
	<xsd:group name="MODE-SWITCHED-ACK-REQUEST">
		<xsd:annotation>
			<xsd:documentation>
			Requests acknowledgements that a mode switch has been proceeded successfully
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="TIMEOUT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of seconds before an error is reported or in case of allowed redundancy, the value is sent again.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::ModeSwitchedAckRequest -->
	<xsd:complexType name="MODE-SWITCHED-ACK-REQUEST" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Requests acknowledgements that a mode switch has been proceeded successfully
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MODE-SWITCHED-ACK-REQUEST"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::SenderComSpec -->
	<xsd:group name="SENDER-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes for a sender port (P-Port and sender-receiver interface).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREF" type="AR:SENDER-COM-SPEC--DATA-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="TRANSMISSION-ACKNOWLEDGE" type="AR:TRANSMISSION-ACKNOWLEDGEMENT-REQUEST" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class Communication::TransmissionAcknowledgementRequest -->
	<xsd:group name="TRANSMISSION-ACKNOWLEDGEMENT-REQUEST">
		<xsd:annotation>
			<xsd:documentation>
			Requests transmission acknowledgement that data has been sent successfully. Success/failure is reported via a SendPoint of a Runnable.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="TIMEOUT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of seconds before an error is reported or in case of allowed redundancy, the value is sent again.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::TransmissionAcknowledgementRequest -->
	<xsd:complexType name="TRANSMISSION-ACKNOWLEDGEMENT-REQUEST" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Requests transmission acknowledgement that data has been sent successfully. Success/failure is reported via a SendPoint of a Runnable.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:TRANSMISSION-ACKNOWLEDGEMENT-REQUEST"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::UnqueuedSenderComSpec -->
	<xsd:group name="UNQUEUED-SENDER-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes specific to distribution of data (P-Port, sender-receiver interface and data element carries &quot;data&quot; opposed to carrying an &quot;event&quot;).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CAN-INVALIDATE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Flag whether the component can actively invalidate data.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="INIT-VALUE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:VALUE-SPECIFICATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::UnqueuedSenderComSpec -->
	<xsd:complexType name="UNQUEUED-SENDER-COM-SPEC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes specific to distribution of data (P-Port, sender-receiver interface and data element carries &quot;data&quot; opposed to carrying an &quot;event&quot;).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-COM-SPEC"/>
			<xsd:group ref="AR:UNQUEUED-SENDER-COM-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Communication::QueuedSenderComSpec -->
	<xsd:complexType name="QUEUED-SENDER-COM-SPEC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes specific to distribution of  events (P-Port, sender-receiver interface and data element carries an &quot;event&quot;).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-COM-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::ServerComSpec -->
	<xsd:group name="SERVER-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes for a server port (P-Port and client-server interface).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OPERATION-IREF" type="AR:SERVER-COM-SPEC--OPERATION-IREF" minOccurs="0"/>
			<xsd:element name="QUEUE-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Length of call queue on the server side. The queue is implemented by the RTE.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::ServerComSpec -->
	<xsd:complexType name="SERVER-COM-SPEC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes for a server port (P-Port and client-server interface).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SERVER-COM-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::ReceiverComSpec -->
	<xsd:group name="RECEIVER-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Receiver specific communication attributes (R-Port and sender-receiver interface).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREF" type="AR:RECEIVER-COM-SPEC--DATA-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="FILTER" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0">
						<xsd:element name="ALWAYS" type="AR:ALWAYS"/>
						<xsd:element name="MASKED-NEW-DIFFERS-MASKED-OLD" type="AR:MASKED-NEW-DIFFERS-MASKED-OLD"/>
						<xsd:element name="MASKED-NEW-DIFFERS-X" type="AR:MASKED-NEW-DIFFERS-X"/>
						<xsd:element name="MASKED-NEW-EQUALS-MASKED-OLD" type="AR:MASKED-NEW-EQUALS-MASKED-OLD"/>
						<xsd:element name="MASKED-NEW-EQUALS-X" type="AR:MASKED-NEW-EQUALS-X"/>
						<xsd:element name="NEVER" type="AR:NEVER"/>
						<xsd:element name="NEW-IS-DIFFERENT" type="AR:NEW-IS-DIFFERENT"/>
						<xsd:element name="NEW-IS-EQUAL" type="AR:NEW-IS-EQUAL"/>
						<xsd:element name="NEW-IS-GREATER" type="AR:NEW-IS-GREATER"/>
						<xsd:element name="NEW-IS-GREATER-OR-EQUAL" type="AR:NEW-IS-GREATER-OR-EQUAL"/>
						<xsd:element name="NEW-IS-LESS" type="AR:NEW-IS-LESS"/>
						<xsd:element name="NEW-IS-LESS-OR-EQUAL" type="AR:NEW-IS-LESS-OR-EQUAL"/>
						<xsd:element name="NEW-IS-OUTSIDE" type="AR:NEW-IS-OUTSIDE"/>
						<xsd:element name="NEW-IS-WITHIN" type="AR:NEW-IS-WITHIN"/>
						<xsd:element name="ONE-EVERY-N" type="AR:ONE-EVERY-N"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class Communication::UnqueuedReceiverComSpec -->
	<xsd:group name="UNQUEUED-RECEIVER-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes specific to reciving data (opposed to receiving events).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ALIVE-TIMEOUT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specify the amount of time (in seconds) after which the software component (via the RTE)  needs to be notified if the corresponding data item have not been received according to the specified timing description.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="HANDLE-INVALID" type="AR:HANDLE-INVALID-TYPE" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies strategy of handling the reception of invalidValue.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="INIT-VALUE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:VALUE-SPECIFICATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RESYNC-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Time allowed for resynchronization of data values after current data is lost, e.g. after an ECU reset.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::UnqueuedReceiverComSpec -->
	<xsd:complexType name="UNQUEUED-RECEIVER-COM-SPEC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes specific to reciving data (opposed to receiving events).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:RECEIVER-COM-SPEC"/>
			<xsd:group ref="AR:UNQUEUED-RECEIVER-COM-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::QueuedReceiverComSpec -->
	<xsd:group name="QUEUED-RECEIVER-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes specific to reciving events.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="QUEUE-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Length of queue for received events.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::QueuedReceiverComSpec -->
	<xsd:complexType name="QUEUED-RECEIVER-COM-SPEC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes specific to reciving events.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:RECEIVER-COM-SPEC"/>
			<xsd:group ref="AR:QUEUED-RECEIVER-COM-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::ClientComSpec -->
	<xsd:group name="CLIENT-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Client specific communication attributes (R-Port and client-server interface).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OPERATION-IREF" type="AR:CLIENT-COM-SPEC--OPERATION-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::ClientComSpec -->
	<xsd:complexType name="CLIENT-COM-SPEC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Client specific communication attributes (R-Port and client-server interface).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-COM-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::SenderReceiverConnectorComSpec -->
	<xsd:group name="SENDER-RECEIVER-CONNECTOR-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes for connectors between sender and receiver ports.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREF" type="AR:SENDER-RECEIVER-CONNECTOR-COM-SPEC--DATA-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="MAX-RESPONSE-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum allowed time (seconds) for date transfer via this connector. The time has to be measured from the moment, at which the information to be sent has been made available by the sending component at its P-Port until it is ready to be used by the receiving component at its R-Port.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-RESPONSE-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Minimum allowed time (seconds) for date transfer via this connector. The time has to be measured from the moment, at which the information to be sent has been made available by the sending component at its P-Port until it is ready to be used by the receiving component at its R-Port. Note that in many cases the minimum required time will be zero.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::SenderReceiverConnectorComSpec -->
	<xsd:complexType name="SENDER-RECEIVER-CONNECTOR-COM-SPEC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes for connectors between sender and receiver ports.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-RECEIVER-CONNECTOR-COM-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::ClientServerConnectorComSpec -->
	<xsd:group name="CLIENT-SERVER-CONNECTOR-COM-SPEC">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes for connectors between client and server ports.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OPERATION-IREF" type="AR:CLIENT-SERVER-CONNECTOR-COM-SPEC--OPERATION-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::ClientServerConnectorComSpec -->
	<xsd:complexType name="CLIENT-SERVER-CONNECTOR-COM-SPEC" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Communication attributes for connectors between client and server ports.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-CONNECTOR-COM-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ClientComSpec_operation -->
	<xsd:group name="CLIENT-COM-SPEC--OPERATION-IREF">
		<xsd:sequence>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OPERATION-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OPERATION-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ClientComSpec_operation -->
	<xsd:complexType name="CLIENT-COM-SPEC--OPERATION-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-COM-SPEC--OPERATION-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ClientServerConnectorComSpec_operation -->
	<xsd:group name="CLIENT-SERVER-CONNECTOR-COM-SPEC--OPERATION-IREF">
		<xsd:sequence>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OPERATION-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OPERATION-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ClientServerConnectorComSpec_operation -->
	<xsd:complexType name="CLIENT-SERVER-CONNECTOR-COM-SPEC--OPERATION-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-CONNECTOR-COM-SPEC--OPERATION-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ReceiverComSpec_dataElement -->
	<xsd:group name="RECEIVER-COM-SPEC--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ReceiverComSpec_dataElement -->
	<xsd:complexType name="RECEIVER-COM-SPEC--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:RECEIVER-COM-SPEC--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SenderComSpec_dataElement -->
	<xsd:group name="SENDER-COM-SPEC--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="P-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:P-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SenderComSpec_dataElement -->
	<xsd:complexType name="SENDER-COM-SPEC--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-COM-SPEC--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SenderReceiverConnectorComSpec_dataElement -->
	<xsd:group name="SENDER-RECEIVER-CONNECTOR-COM-SPEC--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SenderReceiverConnectorComSpec_dataElement -->
	<xsd:complexType name="SENDER-RECEIVER-CONNECTOR-COM-SPEC--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-RECEIVER-CONNECTOR-COM-SPEC--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ServerComSpec_operation -->
	<xsd:group name="SERVER-COM-SPEC--OPERATION-IREF">
		<xsd:sequence>
			<xsd:element name="P-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:P-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OPERATION-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OPERATION-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ServerComSpec_operation -->
	<xsd:complexType name="SERVER-COM-SPEC--OPERATION-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SERVER-COM-SPEC--OPERATION-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Filter::Always -->
	<xsd:complexType name="ALWAYS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			No filtering is performed so that the message always passes.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Filter::MaskedNewDiffersMaskedOld -->
	<xsd:group name="MASKED-NEW-DIFFERS-MASKED-OLD">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages where the masked value has changed.

(new_value&amp;mask) !=(old_value&amp;mask)
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MASK" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			mask for old and new value
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Filter::MaskedNewDiffersMaskedOld -->
	<xsd:complexType name="MASKED-NEW-DIFFERS-MASKED-OLD" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages where the masked value has changed.

(new_value&amp;mask) !=(old_value&amp;mask)
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MASKED-NEW-DIFFERS-MASKED-OLD"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Filter::MaskedNewDiffersX -->
	<xsd:group name="MASKED-NEW-DIFFERS-X">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages whose masked value is not equal to a specific value x

(new_value&amp;mask) != x
new_value: current value of the message
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MASK" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			mask for the new Value
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="X" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Value to compare with
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Filter::MaskedNewDiffersX -->
	<xsd:complexType name="MASKED-NEW-DIFFERS-X" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages whose masked value is not equal to a specific value x

(new_value&amp;mask) != x
new_value: current value of the message
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MASKED-NEW-DIFFERS-X"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Filter::MaskedNewEqualsMaskedOld -->
	<xsd:group name="MASKED-NEW-EQUALS-MASKED-OLD">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages where the masked value has not changed.

(new_value&amp;mask) ==(old_value&amp;mask)
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MASK" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			mask for old and new value
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Filter::MaskedNewEqualsMaskedOld -->
	<xsd:complexType name="MASKED-NEW-EQUALS-MASKED-OLD" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages where the masked value has not changed.

(new_value&amp;mask) ==(old_value&amp;mask)
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MASKED-NEW-EQUALS-MASKED-OLD"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Filter::MaskedNewEqualsX -->
	<xsd:group name="MASKED-NEW-EQUALS-X">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages whose masked value is equal to a specific value x

(new_value&amp;mask) == x
new_value: current value of the message
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MASK" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			mask for the new Value
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="X" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Value to compare with
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Filter::MaskedNewEqualsX -->
	<xsd:complexType name="MASKED-NEW-EQUALS-X" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages whose masked value is equal to a specific value x

(new_value&amp;mask) == x
new_value: current value of the message
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MASKED-NEW-EQUALS-X"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Filter::Never -->
	<xsd:complexType name="NEVER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The filter removes all messages.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Filter::NewIsDifferent -->
	<xsd:complexType name="NEW-IS-DIFFERENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages which have changed.

newValue != oldValue
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Filter::NewIsEqual -->
	<xsd:complexType name="NEW-IS-EQUAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass messages which have not changed.

newValue == oldValue
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Filter::NewIsGreater -->
	<xsd:complexType name="NEW-IS-GREATER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message if its value has increased.

new_value &gt; old_value
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Filter::NewIsGreaterOrEqual -->
	<xsd:complexType name="NEW-IS-GREATER-OR-EQUAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message if its value has not decreased.

new_value &gt;= old_value
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Filter::NewIsLess -->
	<xsd:complexType name="NEW-IS-LESS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message if its value has decreased.

new_value &lt; old_value
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Filter::NewIsLessOrEqual -->
	<xsd:complexType name="NEW-IS-LESS-OR-EQUAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message if its value has not increased.

new_value &lt;= old_value
new_value: current value of the message
old_value: last value of the message (initialised with the initial value of the message, updated with new_value if the new message value is not filtered out)

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Filter::NewIsOutside -->
	<xsd:group name="NEW-IS-OUTSIDE">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message if its value is outside a predefined boundary.

(min &gt; new_value) OR (new_value &gt; max)
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MAX" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Value to specify the lower bounddary
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Value to specify the lower bounddary
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Filter::NewIsOutside -->
	<xsd:complexType name="NEW-IS-OUTSIDE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message if its value is outside a predefined boundary.

(min &gt; new_value) OR (new_value &gt; max)
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:NEW-IS-OUTSIDE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Filter::NewIsWithin -->
	<xsd:group name="NEW-IS-WITHIN">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message if its value is within a predefined boundary.

min &lt;= new_value &lt;= max
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MAX" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Value to specify the lower bounddary
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Value to specify the lower bounddary
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Filter::NewIsWithin -->
	<xsd:complexType name="NEW-IS-WITHIN" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message if its value is within a predefined boundary.

min &lt;= new_value &lt;= max
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:NEW-IS-WITHIN"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Filter::OneEveryN -->
	<xsd:group name="ONE-EVERY-N">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message once every N message occurrences.
Start: occurrence = 0.
Each time the message is received or transmitted, occurrence is incremented by 1 after filtering.
Length of occurrence is 8 bit (minimum).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OCCURRENCE" type="xsd:integer" minOccurs="0"/>
			<xsd:element name="OFFSET" type="xsd:integer" minOccurs="0"/>
			<xsd:element name="PERIOD" type="xsd:integer" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Filter::OneEveryN -->
	<xsd:complexType name="ONE-EVERY-N" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Pass a message once every N message occurrences.
Start: occurrence = 0.
Each time the message is received or transmitted, occurrence is incremented by 1 after filtering.
Length of occurrence is 8 bit (minimum).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ONE-EVERY-N"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class VFBErrors::DevelopmentError -->
	<xsd:complexType name="DEVELOPMENT-ERROR" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			These errors are tracked by DET. They are not relevant for the production environment. Not further examined as of now.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class VFBErrors::ApplicationError -->
	<xsd:group name="APPLICATION-ERROR">
		<xsd:annotation>
			<xsd:documentation>
			This is a user-defined error that is associated with an element of an AUTOSAR interface. It is specific for the particular functionality or service provided by the AUTOSAR software component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ERROR-CODE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The RTE generator is forced to assign this value to the corresponding error symbol. Note that for error codes certain ranges are predefined (see RTE specification).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class VFBErrors::ApplicationError -->
	<xsd:complexType name="APPLICATION-ERROR" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This is a user-defined error that is associated with an element of an AUTOSAR interface. It is specific for the particular functionality or service provided by the AUTOSAR software component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:APPLICATION-ERROR"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="APPLICATION-ERROR--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="APPLICATION-ERROR"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Constants::ArraySpecification -->
	<xsd:group name="ARRAY-SPECIFICATION">
		<xsd:annotation>
			<xsd:documentation>
			A constant array, which refers to its elements by index.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ELEMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ARRAY-SPECIFICATION" type="AR:ARRAY-SPECIFICATION"/>
						<xsd:element name="BOOLEAN-LITERAL" type="AR:BOOLEAN-LITERAL"/>
						<xsd:element name="CHAR-LITERAL" type="AR:CHAR-LITERAL"/>
						<xsd:element name="CONSTANT-REFERENCE" type="AR:CONSTANT-REFERENCE"/>
						<xsd:element name="INTEGER-LITERAL" type="AR:INTEGER-LITERAL"/>
						<xsd:element name="OPAQUE-LITERAL" type="AR:OPAQUE-LITERAL"/>
						<xsd:element name="REAL-LITERAL" type="AR:REAL-LITERAL"/>
						<xsd:element name="RECORD-SPECIFICATION" type="AR:RECORD-SPECIFICATION"/>
						<xsd:element name="STRING-LITERAL" type="AR:STRING-LITERAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::ArraySpecification -->
	<xsd:complexType name="ARRAY-SPECIFICATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A constant array, which refers to its elements by index.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:ARRAY-SPECIFICATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="VALUE-SPECIFICATION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ARRAY-SPECIFICATION"/>
			<xsd:enumeration value="BOOLEAN-LITERAL"/>
			<xsd:enumeration value="CHAR-LITERAL"/>
			<xsd:enumeration value="CONSTANT-REFERENCE"/>
			<xsd:enumeration value="INTEGER-LITERAL"/>
			<xsd:enumeration value="OPAQUE-LITERAL"/>
			<xsd:enumeration value="REAL-LITERAL"/>
			<xsd:enumeration value="RECORD-SPECIFICATION"/>
			<xsd:enumeration value="STRING-LITERAL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Constants::BooleanLiteral -->
	<xsd:group name="BOOLEAN-LITERAL">
		<xsd:annotation>
			<xsd:documentation>
			Boolean constant expression.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The Boolean value.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::BooleanLiteral -->
	<xsd:complexType name="BOOLEAN-LITERAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Boolean constant expression.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:BOOLEAN-LITERAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Constants::CharLiteral -->
	<xsd:group name="CHAR-LITERAL">
		<xsd:annotation>
			<xsd:documentation>
			Character constant description.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The character value (a string of length 1).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::CharLiteral -->
	<xsd:complexType name="CHAR-LITERAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Character constant description.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:CHAR-LITERAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Constants::ConstantReference -->
	<xsd:group name="CONSTANT-REFERENCE">
		<xsd:annotation>
			<xsd:documentation>
			Instead of defining this constant inline, another constant is referenced.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONSTANT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CONSTANT-SPECIFICATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::ConstantReference -->
	<xsd:complexType name="CONSTANT-REFERENCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Instead of defining this constant inline, another constant is referenced.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:CONSTANT-REFERENCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Constants::ConstantSpecification -->
	<xsd:group name="CONSTANT-SPECIFICATION">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a constant that can be part of a package, i.e. it can be defined stand-alone.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0">
						<xsd:element name="ARRAY-SPECIFICATION" type="AR:ARRAY-SPECIFICATION"/>
						<xsd:element name="BOOLEAN-LITERAL" type="AR:BOOLEAN-LITERAL"/>
						<xsd:element name="CHAR-LITERAL" type="AR:CHAR-LITERAL"/>
						<xsd:element name="CONSTANT-REFERENCE" type="AR:CONSTANT-REFERENCE"/>
						<xsd:element name="INTEGER-LITERAL" type="AR:INTEGER-LITERAL"/>
						<xsd:element name="OPAQUE-LITERAL" type="AR:OPAQUE-LITERAL"/>
						<xsd:element name="REAL-LITERAL" type="AR:REAL-LITERAL"/>
						<xsd:element name="RECORD-SPECIFICATION" type="AR:RECORD-SPECIFICATION"/>
						<xsd:element name="STRING-LITERAL" type="AR:STRING-LITERAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::ConstantSpecification -->
	<xsd:complexType name="CONSTANT-SPECIFICATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a constant that can be part of a package, i.e. it can be defined stand-alone.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:CONSTANT-SPECIFICATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="CONSTANT-SPECIFICATION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CONSTANT-SPECIFICATION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Constants::IntegerLiteral -->
	<xsd:group name="INTEGER-LITERAL">
		<xsd:annotation>
			<xsd:documentation>
			Constant integer value.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The value.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::IntegerLiteral -->
	<xsd:complexType name="INTEGER-LITERAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Constant integer value.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:INTEGER-LITERAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Constants::OpaqueLiteral -->
	<xsd:group name="OPAQUE-LITERAL">
		<xsd:annotation>
			<xsd:documentation>
			An opaque literal.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The string encodes an array of bytes in the following syntax &quot;ae:05:fe&quot;
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::OpaqueLiteral -->
	<xsd:complexType name="OPAQUE-LITERAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An opaque literal.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:OPAQUE-LITERAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Constants::RealLiteral -->
	<xsd:group name="REAL-LITERAL">
		<xsd:annotation>
			<xsd:documentation>
			Constant description for real values.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The numeric value itself.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::RealLiteral -->
	<xsd:complexType name="REAL-LITERAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Constant description for real values.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:REAL-LITERAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Constants::RecordSpecification -->
	<xsd:group name="RECORD-SPECIFICATION">
		<xsd:sequence>
			<xsd:element name="ELEMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ARRAY-SPECIFICATION" type="AR:ARRAY-SPECIFICATION"/>
						<xsd:element name="BOOLEAN-LITERAL" type="AR:BOOLEAN-LITERAL"/>
						<xsd:element name="CHAR-LITERAL" type="AR:CHAR-LITERAL"/>
						<xsd:element name="CONSTANT-REFERENCE" type="AR:CONSTANT-REFERENCE"/>
						<xsd:element name="INTEGER-LITERAL" type="AR:INTEGER-LITERAL"/>
						<xsd:element name="OPAQUE-LITERAL" type="AR:OPAQUE-LITERAL"/>
						<xsd:element name="REAL-LITERAL" type="AR:REAL-LITERAL"/>
						<xsd:element name="RECORD-SPECIFICATION" type="AR:RECORD-SPECIFICATION"/>
						<xsd:element name="STRING-LITERAL" type="AR:STRING-LITERAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::RecordSpecification -->
	<xsd:complexType name="RECORD-SPECIFICATION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:RECORD-SPECIFICATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Constants::StringLiteral -->
	<xsd:group name="STRING-LITERAL">
		<xsd:annotation>
			<xsd:documentation>
			A constant string.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The string itself.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Constants::StringLiteral -->
	<xsd:complexType name="STRING-LITERAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A constant string.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:STRING-LITERAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ValueModel::V -->
	<xsd:complexType name="V" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;v&gt; to enter a numerical value.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			msr.id="type__V_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ValueModel::Vf -->
	<xsd:complexType name="VF" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			Value calculated via a system constant. This element is included in every case, where parameters should be generated from numerical values during compile time (not runtime!). Thus for example, the influence of the cylinder number on conversion formulae, can be introduced in a repeatable manner.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.useCase="MDX";msr.id="type__VF_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- attribute group for class ValueModel::Vt -->
	<xsd:attributeGroup name="VT">
		<xsd:annotation>
			<xsd:documentation>
			&lt;vt&gt; represents one particular textual value of the calibration item.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="VT";asam.useCase="MDX";msr.id="type__VT_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:attribute name="XMLSPACE" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class ValueModel::Vt -->
	<xsd:complexType name="VT" abstract="false" mixed="true">
		<xsd:annotation>
			<xsd:documentation>
			&lt;vt&gt; represents one particular textual value of the calibration item.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="VT";asam.useCase="MDX";msr.id="type__VT_TYPE";msr.isGroupOnly="true"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:VT"/>
	</xsd:complexType>
	<!-- complex type for class LocalConstraints::Interstring -->
	<xsd:complexType name="INTERSTRING" abstract="false" mixed="false">
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="INTERVAL-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="OPEN"/>
			<xsd:enumeration value="INFINITE"/>
			<xsd:enumeration value="CLOSED"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- attribute group for class LocalConstraints::Limit -->
	<xsd:attributeGroup name="LIMIT">
		<xsd:attribute name="INTERVAL-TYPE" type="AR:INTERVAL-TYPE-ENUM"/>
	</xsd:attributeGroup>
	<!-- complex type for class LocalConstraints::Limit -->
	<xsd:complexType name="LIMIT" abstract="false" mixed="true">
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:LIMIT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::Compu -->
	<xsd:group name="COMPU">
		<xsd:sequence>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:COMPU-PROG-CODE"/>
				<xsd:group ref="AR:COMPU-SCALES"/>
			</xsd:choice>
			<xsd:element name="COMPU-DEFAULT-VALUE" type="AR:COMPU-CONST" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::Compu -->
	<xsd:complexType name="COMPU" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuConst -->
	<xsd:group name="COMPU-CONST">
		<xsd:sequence>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:COMPU-CONST-FORMULA-CONTENT"/>
				<xsd:group ref="AR:COMPU-CONST-NUMERIC-CONTENT"/>
				<xsd:group ref="AR:COMPU-CONST-TEXT-CONTENT"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuConst -->
	<xsd:complexType name="COMPU-CONST" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-CONST"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuConstFormulaContent -->
	<xsd:group name="COMPU-CONST-FORMULA-CONTENT">
		<xsd:sequence>
			<xsd:element name="VF" type="AR:VF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuConstFormulaContent -->
	<xsd:complexType name="COMPU-CONST-FORMULA-CONTENT" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-CONST-FORMULA-CONTENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuConstNumericContent -->
	<xsd:group name="COMPU-CONST-NUMERIC-CONTENT">
		<xsd:sequence>
			<xsd:element name="V" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Use &lt;v&gt; to enter a numerical value.
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="COMPU-CONST_numericContent_TYPE__V";msr.tbdString="true";xml.sequenceOffset="50"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuConstNumericContent -->
	<xsd:complexType name="COMPU-CONST-NUMERIC-CONTENT" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-CONST-NUMERIC-CONTENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuConstTextContent -->
	<xsd:group name="COMPU-CONST-TEXT-CONTENT">
		<xsd:sequence>
			<xsd:element name="VT" type="AR:VT" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuConstTextContent -->
	<xsd:complexType name="COMPU-CONST-TEXT-CONTENT" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-CONST-TEXT-CONTENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ComputationMethod::CompuDefaultValue -->
	<xsd:complexType name="COMPU-DEFAULT-VALUE" abstract="false" mixed="false">
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- attribute group for class ComputationMethod::CompuGenericMath -->
	<xsd:attributeGroup name="COMPU-GENERIC-MATH">
		<xsd:attribute name="LEVEL" type="xsd:string"/>
	</xsd:attributeGroup>
	<!-- complex type for class ComputationMethod::CompuGenericMath -->
	<xsd:complexType name="COMPU-GENERIC-MATH" abstract="false" mixed="true">
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:COMPU-GENERIC-MATH"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuMethod -->
	<xsd:group name="COMPU-METHOD">
		<xsd:annotation>
			<xsd:documentation>
			This represents the so called computation method describing the method how to convert between a physical value and a numerical value. See ASAM-HDO specification for details. 
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-COMPU-METHOD";asam.useCase="MDX";msr.id="type__COMPU-METHOD_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="UNIT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:UNIT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPU-INTERNAL-TO-PHYS" type="AR:COMPU" minOccurs="0"/>
			<xsd:element name="COMPU-PHYS-TO-INTERNAL" type="AR:COMPU" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuMethod -->
	<xsd:complexType name="COMPU-METHOD" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This represents the so called computation method describing the method how to convert between a physical value and a numerical value. See ASAM-HDO specification for details. 
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-COMPU-METHOD";asam.useCase="MDX";msr.id="type__COMPU-METHOD_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMPU-METHOD"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMPU-METHOD--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMPU-METHOD"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ComputationMethod::CompuNominatorDenominator -->
	<xsd:group name="COMPU-NOMINATOR-DENOMINATOR">
		<xsd:choice>
			<xsd:choice minOccurs="0" maxOccurs="unbounded">
				<xsd:element name="VF" type="AR:VF" minOccurs="0" maxOccurs="unbounded"/>
				<xsd:element name="V" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
					<xsd:annotation>
						<xsd:documentation>
			Use &lt;v&gt; to enter a numerical value.
		</xsd:documentation>
						<xsd:appinfo source="tags">
		   			xml.sequenceOffset="30";msr.id="COMPU-NOMINATOR_DENOMINATOR_TYPE__V"
		  	 </xsd:appinfo>
					</xsd:annotation>
				</xsd:element>
			</xsd:choice>
		</xsd:choice>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuNominatorDenominator -->
	<xsd:complexType name="COMPU-NOMINATOR-DENOMINATOR" abstract="false" mixed="false">
		<xsd:choice minOccurs="0" maxOccurs="unbounded">
			<xsd:group ref="AR:COMPU-NOMINATOR-DENOMINATOR"/>
		</xsd:choice>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuProgCode -->
	<xsd:group name="COMPU-PROG-CODE">
		<xsd:sequence>
			<xsd:element name="PROG-CODE" type="AR:PROG-CODE" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuProgCode -->
	<xsd:complexType name="COMPU-PROG-CODE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-PROG-CODE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ComputationMethod::ProgCode -->
	<xsd:complexType name="PROG-CODE" abstract="false" mixed="false">
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuRationalCoeffs -->
	<xsd:group name="COMPU-RATIONAL-COEFFS">
		<xsd:sequence>
			<xsd:element name="COMPU-NUMERATOR" type="AR:COMPU-NOMINATOR-DENOMINATOR" minOccurs="0"/>
			<xsd:element name="COMPU-DENOMINATOR" type="AR:COMPU-NOMINATOR-DENOMINATOR" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuRationalCoeffs -->
	<xsd:complexType name="COMPU-RATIONAL-COEFFS" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-RATIONAL-COEFFS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuScale -->
	<xsd:group name="COMPU-SCALE">
		<xsd:sequence>
			<xsd:element name="SHORT-LABEL" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This element specifies a short name for the context element. This label cannot be referenced in the same way as a &lt;shortName&gt; in connection with MSRSW (queries, external applications etc.).
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			msr.id="COMPU-SCALE_TYPE__SHORT-LABEL";msr.tbdString="true";xml.sequenceOffset="20"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DESC" type="AR:ML-DATA-2" minOccurs="0"/>
			<xsd:element name="LOWER-LIMIT" type="AR:LIMIT" minOccurs="0"/>
			<xsd:element name="UPPER-LIMIT" type="AR:LIMIT" minOccurs="0"/>
			<xsd:choice minOccurs="0">
				<xsd:group ref="AR:COMPU-SCALE-CONSTANT-CONTENTS"/>
				<xsd:group ref="AR:COMPU-SCALE-RATIONAL-FORMULA"/>
			</xsd:choice>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuScale -->
	<xsd:complexType name="COMPU-SCALE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-SCALE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuScaleConstantContents -->
	<xsd:group name="COMPU-SCALE-CONSTANT-CONTENTS">
		<xsd:sequence>
			<xsd:element name="COMPU-CONST" type="AR:COMPU-CONST" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuScaleConstantContents -->
	<xsd:complexType name="COMPU-SCALE-CONSTANT-CONTENTS" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-SCALE-CONSTANT-CONTENTS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ComputationMethod::CompuScaleGenericMath -->
	<xsd:complexType name="COMPU-SCALE-GENERIC-MATH" abstract="false" mixed="false">
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuScaleRationalFormula -->
	<xsd:group name="COMPU-SCALE-RATIONAL-FORMULA">
		<xsd:sequence>
			<xsd:element name="COMPU-RATIONAL-COEFFS" type="AR:COMPU-RATIONAL-COEFFS" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuScaleRationalFormula -->
	<xsd:complexType name="COMPU-SCALE-RATIONAL-FORMULA" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-SCALE-RATIONAL-FORMULA"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ComputationMethod::CompuScales -->
	<xsd:group name="COMPU-SCALES">
		<xsd:sequence>
			<xsd:element name="COMPU-SCALES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMPU-SCALE" type="AR:COMPU-SCALE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ComputationMethod::CompuScales -->
	<xsd:complexType name="COMPU-SCALES" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPU-SCALES"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Units::DisplayName -->
	<xsd:complexType name="DISPLAY-NAME" abstract="false" mixed="true">
		<xsd:choice minOccurs="0" maxOccurs="unbounded"/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Units::PhysicalDimension -->
	<xsd:group name="PHYSICAL-DIMENSION">
		<xsd:sequence>
			<xsd:element name="LENGTH-EXP" type="xsd:string" minOccurs="0"/>
			<xsd:element name="MASS-EXP" type="xsd:string" minOccurs="0"/>
			<xsd:element name="TIME-EXP" type="xsd:string" minOccurs="0"/>
			<xsd:element name="CURRENT-EXP" type="xsd:string" minOccurs="0"/>
			<xsd:element name="TEMPERATURE-EXP" type="xsd:string" minOccurs="0"/>
			<xsd:element name="MOLAR-AMOUNT-EXP" type="xsd:string" minOccurs="0"/>
			<xsd:element name="LUMINOUS-INTENSITY-EXP" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Units::PhysicalDimension -->
	<xsd:complexType name="PHYSICAL-DIMENSION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PHYSICAL-DIMENSION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="PHYSICAL-DIMENSION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PHYSICAL-DIMENSION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Units::UnitGroup -->
	<xsd:group name="UNIT-GROUP">
		<xsd:sequence>
			<xsd:element name="UNIT-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="UNIT-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:UNIT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Units::UnitGroup -->
	<xsd:complexType name="UNIT-GROUP" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:UNIT-GROUP"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Units::UnitSpec -->
	<xsd:group name="UNIT-SPEC">
		<xsd:sequence>
			<xsd:element name="UNIT-GROUPS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="UNIT-GROUP" type="AR:UNIT-GROUP"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="UNITS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="UNIT" type="AR:UNIT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PHYSICAL-DIMENSIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PHYSICAL-DIMENSION" type="AR:PHYSICAL-DIMENSION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Units::UnitSpec -->
	<xsd:complexType name="UNIT-SPEC" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:UNIT-SPEC"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Units::Unit -->
	<xsd:group name="UNIT">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;unit&gt; to enter the unit of a parameter.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-UNIT";asam.useCase="MDX";msr.id="type__UNIT_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DISPLAY-NAME" type="AR:SL-DATA-3" minOccurs="0"/>
			<xsd:element name="FACTOR-SI-TO-UNIT" type="xsd:string" minOccurs="0"/>
			<xsd:element name="OFFSET-SI-TO-UNIT" type="xsd:string" minOccurs="0"/>
			<xsd:element name="PHYSICAL-DIMENSION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PHYSICAL-DIMENSION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Units::Unit -->
	<xsd:complexType name="UNIT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Use &lt;unit&gt; to enter the unit of a parameter.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			asam.harmonizedObject="ASAM-UNIT";asam.useCase="MDX";msr.id="type__UNIT_TYPE"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:UNIT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="UNIT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="UNIT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Datatypes::ARLimit -->
	<xsd:group name="AR-LIMIT">
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- attribute group for class Datatypes::ARLimit -->
	<xsd:attributeGroup name="AR-LIMIT">
		<xsd:attribute name="INTERVAL-TYPE" type="AR:INTERVAL-TYPE-ENUM"/>
	</xsd:attributeGroup>
	<!-- complex type for class Datatypes::ARLimit -->
	<xsd:complexType name="AR-LIMIT">
		<xsd:simpleContent>
			<xsd:extension base="xsd:string">
				<xsd:attributeGroup ref="AR:AR-OBJECT"/>
				<xsd:attributeGroup ref="AR:AR-LIMIT"/>
			</xsd:extension>
		</xsd:simpleContent>
	</xsd:complexType>
	<!-- element group for class Datatypes::ArrayElement -->
	<xsd:group name="ARRAY-ELEMENT">
		<xsd:sequence>
			<xsd:element name="MAX-NUMBER-OF-ELEMENTS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maximum number of elements that the array can contain.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Datatypes::ArrayElement -->
	<xsd:complexType name="ARRAY-ELEMENT" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:ARRAY-ELEMENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ARRAY-ELEMENT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ARRAY-ELEMENT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Datatypes::BooleanType -->
	<xsd:complexType name="BOOLEAN-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This datatype represents a set containing the logical value true and false

		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.Boolean"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PRIMITIVE-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Datatypes::PrimitiveType -->
	<xsd:group name="PRIMITIVE-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			A primitive datatype consists of a set of allowed values.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-DATA-DEF-PROPS" type="AR:SW-DATA-DEF-PROPS" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="DATATYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ARRAY-TYPE"/>
			<xsd:enumeration value="BOOLEAN-TYPE"/>
			<xsd:enumeration value="CHAR-TYPE"/>
			<xsd:enumeration value="INTEGER-TYPE"/>
			<xsd:enumeration value="OPAQUE-TYPE"/>
			<xsd:enumeration value="REAL-TYPE"/>
			<xsd:enumeration value="RECORD-TYPE"/>
			<xsd:enumeration value="STRING-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Datatypes::OpaqueType -->
	<xsd:group name="OPAQUE-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			This Datatype represents an array of exactly numberOfBits bits.  It is called &quot;opaque&quot; because this array of bits should be transported &quot;as is&quot; by the AUTOSAR RTE.

		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.String"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="NUMBER-OF-BITS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of bits that are used to make up the opaque type.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Datatypes::OpaqueType -->
	<xsd:complexType name="OPAQUE-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This Datatype represents an array of exactly numberOfBits bits.  It is called &quot;opaque&quot; because this array of bits should be transported &quot;as is&quot; by the AUTOSAR RTE.

		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.String"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PRIMITIVE-TYPE"/>
			<xsd:group ref="AR:OPAQUE-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Datatypes::Range -->
	<xsd:group name="RANGE">
		<xsd:annotation>
			<xsd:documentation>
			Abstract class for specifying a range from lower limit to upper limit. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="LOWER-LIMIT" type="AR:AR-LIMIT" minOccurs="0"/>
			<xsd:element name="UPPER-LIMIT" type="AR:AR-LIMIT" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Datatypes::RecordElement -->
	<xsd:complexType name="RECORD-ELEMENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An element in a record. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="RECORD-ELEMENT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="RECORD-ELEMENT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Datatypes::StringType -->
	<xsd:group name="STRING-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			This represents a string of characters out of the character-set specified by the given encoding.
The maxNumberOfChars is the maximal number of characters which can be stored within the String. The actual number of bytes that is required to represent the string can be calculated out of maxNumberOfChars and the encoding:

bytes required to represent the string =
maxNumberOfChars * (max bytes per character using the given encoding) + 1 (terminating null)

		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.String"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ENCODING" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specification of character encoding, e. g. ISO-8859-1.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-NUMBER-OF-CHARS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maxNumberOfChars is the maximum number of characters that can be stored in the string. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Datatypes::StringType -->
	<xsd:complexType name="STRING-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This represents a string of characters out of the character-set specified by the given encoding.
The maxNumberOfChars is the maximal number of characters which can be stored within the String. The actual number of bytes that is required to represent the string can be calculated out of maxNumberOfChars and the encoding:

bytes required to represent the string =
maxNumberOfChars * (max bytes per character using the given encoding) + 1 (terminating null)

		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.String"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PRIMITIVE-TYPE"/>
			<xsd:group ref="AR:STRING-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class Datatypes::IntegerType -->
	<xsd:complexType name="INTEGER-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This data-type are the integers in the interval defined by the Range.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.Integer"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PRIMITIVE-TYPE"/>
			<xsd:group ref="AR:RANGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Datatypes::RealType -->
	<xsd:group name="REAL-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			This represents a range of reals that can be represented by either the IEEE 754 &quot;Single Precision&quot; (encoding is &quot;Single&quot;) or IEEE 754 &quot;Double Precision&quot; (encoding is &quot;Double&quot;) arithmetic.
Note that these standards include representations for +infinity, -infinity, QNaN and SNaN.  When defining a RealType, one must indicate whether these special values are allowed or not. 



		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.Float"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ALLOW-NAN" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Denotes whether this data type permits for &quot;not a number&quot; being represented by the type
		</xsd:documentation>
					<xsd:appinfo source="tags">
		   			xml.name="ALLOW-NAN"
		  	 </xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ENCODING" type="AR:REAL-TYPE-ENCODING-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Denotes whether single or double precision is used.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Datatypes::RealType -->
	<xsd:complexType name="REAL-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This represents a range of reals that can be represented by either the IEEE 754 &quot;Single Precision&quot; (encoding is &quot;Single&quot;) or IEEE 754 &quot;Double Precision&quot; (encoding is &quot;Double&quot;) arithmetic.
Note that these standards include representations for +infinity, -infinity, QNaN and SNaN.  When defining a RealType, one must indicate whether these special values are allowed or not. 



		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.Float"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PRIMITIVE-TYPE"/>
			<xsd:group ref="AR:RANGE"/>
			<xsd:group ref="AR:REAL-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="REAL-TYPE-ENCODING-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SINGLE"/>
			<xsd:enumeration value="DOUBLE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Datatypes::CharType -->
	<xsd:group name="CHAR-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			This represents a character belonging to the character-set specified in the encoding.  The semantics are built-in into this datatype.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.Character"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ENCODING" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specification of character encoding, e.g. ISO-8859-1
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Datatypes::CharType -->
	<xsd:complexType name="CHAR-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This represents a character belonging to the character-set specified in the encoding.  The semantics are built-in into this datatype.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			java.instanceClass="java.lang.Character"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PRIMITIVE-TYPE"/>
			<xsd:group ref="AR:CHAR-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Datatypes::ArrayType -->
	<xsd:group name="ARRAY-TYPE">
		<xsd:sequence>
			<xsd:element name="ELEMENT" type="AR:ARRAY-ELEMENT" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Datatypes::ArrayType -->
	<xsd:complexType name="ARRAY-TYPE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:ARRAY-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Datatypes::RecordType -->
	<xsd:group name="RECORD-TYPE">
		<xsd:sequence>
			<xsd:element name="ELEMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="RECORD-ELEMENT" type="AR:RECORD-ELEMENT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Datatypes::RecordType -->
	<xsd:complexType name="RECORD-TYPE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RECORD-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Datatypes::DataPrototype -->
	<xsd:group name="DATA-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			Base class for prototypical roles of a datatype.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SW-DATA-DEF-PROPS" type="AR:SW-DATA-DEF-PROPS" minOccurs="0"/>
			<xsd:element name="TYPE-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATATYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="DATA-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ARGUMENT-PROTOTYPE"/>
			<xsd:enumeration value="ARRAY-ELEMENT"/>
			<xsd:enumeration value="ARRAY-SPECIFICATION"/>
			<xsd:enumeration value="BOOLEAN-LITERAL"/>
			<xsd:enumeration value="CALPRM-ELEMENT-PROTOTYPE"/>
			<xsd:enumeration value="CHAR-LITERAL"/>
			<xsd:enumeration value="CONSTANT-REFERENCE"/>
			<xsd:enumeration value="DATA-ELEMENT-PROTOTYPE"/>
			<xsd:enumeration value="INTEGER-LITERAL"/>
			<xsd:enumeration value="INTER-RUNNABLE-VARIABLE"/>
			<xsd:enumeration value="OPAQUE-LITERAL"/>
			<xsd:enumeration value="PER-INSTANCE-MEMORY-VARIABLE"/>
			<xsd:enumeration value="REAL-LITERAL"/>
			<xsd:enumeration value="RECORD-ELEMENT"/>
			<xsd:enumeration value="RECORD-SPECIFICATION"/>
			<xsd:enumeration value="STRING-LITERAL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Resources::ResourceConsumption -->
	<xsd:group name="RESOURCE-CONSUMPTION">
		<xsd:annotation>
			<xsd:documentation>
			Description of consumed resources by one implementation of a software component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="EXECUTION-TIMES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="EXECUTION-TIME" type="AR:EXECUTION-TIME"/>
						<xsd:element name="MEASURED-EXECUTION-TIME" type="AR:MEASURED-EXECUTION-TIME"/>
						<xsd:element name="ROUGH-ESTIMATE-OF-EXECUTION-TIME" type="AR:ROUGH-ESTIMATE-OF-EXECUTION-TIME"/>
						<xsd:element name="SIMULATED-EXECUTION-TIME" type="AR:SIMULATED-EXECUTION-TIME"/>
						<xsd:element name="WORST-CASE-EXECUTION-TIME" type="AR:WORST-CASE-EXECUTION-TIME"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="HEAP-USAGES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MEASURED-HEAP-USAGE" type="AR:MEASURED-HEAP-USAGE"/>
						<xsd:element name="ROUGH-ESTIMATE-HEAP-USAGE" type="AR:ROUGH-ESTIMATE-HEAP-USAGE"/>
						<xsd:element name="WORST-CASE-HEAP-USAGE" type="AR:WORST-CASE-HEAP-USAGE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OBJECT-FILE-SECTIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="OBJECT-FILE-SECTION" type="AR:OBJECT-FILE-SECTION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PER-INSTANCE-MEMORY-SIZES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PER-INSTANCE-MEMORY-SIZE" type="AR:PER-INSTANCE-MEMORY-SIZE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="STACK-USAGES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MEASURED-STACK-USAGE" type="AR:MEASURED-STACK-USAGE"/>
						<xsd:element name="ROUGH-ESTIMATE-STACK-USAGE" type="AR:ROUGH-ESTIMATE-STACK-USAGE"/>
						<xsd:element name="WORST-CASE-STACK-USAGE" type="AR:WORST-CASE-STACK-USAGE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Resources::ResourceConsumption -->
	<xsd:complexType name="RESOURCE-CONSUMPTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Description of consumed resources by one implementation of a software component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RESOURCE-CONSUMPTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class PerInstanceMemorySize::PerInstanceMemorySize -->
	<xsd:group name="PER-INSTANCE-MEMORY-SIZE">
		<xsd:annotation>
			<xsd:documentation>
			Resources needed by the allocation of PerInstanceMemory for each SWC instance. Note that these resources are not covered by an ObjectFileSection, because they are supposed to be allocated by the RTE.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ALIGNMENT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Required alignment (1,2,4,...) of the referenced PerInstanceMemory
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PER-INSTANCE-MEMORY-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PER-INSTANCE-MEMORY--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIZE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Size (in bytes) of the reference perInstanceMemory
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PerInstanceMemorySize::PerInstanceMemorySize -->
	<xsd:complexType name="PER-INSTANCE-MEMORY-SIZE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Resources needed by the allocation of PerInstanceMemory for each SWC instance. Note that these resources are not covered by an ObjectFileSection, because they are supposed to be allocated by the RTE.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PER-INSTANCE-MEMORY-SIZE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ObjectFileSection::ObjectFileSection -->
	<xsd:group name="OBJECT-FILE-SECTION">
		<xsd:annotation>
			<xsd:documentation>
			The objectFileSection provides additional information to the different sections in the object-file containing the implementation of the SW-C
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ALIGNMENT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The alignment (typically 1, 2, 4,...)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="EXECUTABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Is code stored in this section that needs to be executed. In some processor architectures code execution is only allowed from specific memory sections.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SECTION-NAME" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This is the name of the section in the object-file
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SIZE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The size in bytes of the section.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WRITABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Is it possible to write this section.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ObjectFileSection::ObjectFileSection -->
	<xsd:complexType name="OBJECT-FILE-SECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The objectFileSection provides additional information to the different sections in the object-file containing the implementation of the SW-C
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:OBJECT-FILE-SECTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="OBJECT-FILE-SECTION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="OBJECT-FILE-SECTION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ExecutionTime::ECUPrototype -->
	<xsd:group name="ECU-PROTOTYPE">
		<xsd:sequence>
			<xsd:element name="E-CU-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExecutionTime::ECUPrototype -->
	<xsd:complexType name="ECU-PROTOTYPE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:ECU-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ExecutionTime::HardwareConfiguration -->
	<xsd:group name="HARDWARE-CONFIGURATION">
		<xsd:sequence>
			<xsd:element name="ADDITIONAL-INFORMATION" type="xsd:string" minOccurs="0"/>
			<xsd:element name="PROCESSOR-MODE" type="xsd:string" minOccurs="0"/>
			<xsd:element name="PROCESSOR-SPEED" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExecutionTime::HardwareConfiguration -->
	<xsd:complexType name="HARDWARE-CONFIGURATION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:HARDWARE-CONFIGURATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ExecutionTime::MeasuredExecutionTime -->
	<xsd:group name="MEASURED-EXECUTION-TIME">
		<xsd:sequence>
			<xsd:element name="AVERAGE-EXECUTION-TIME" type="xsd:double" minOccurs="0"/>
			<xsd:element name="MAXIMAL-EXECUTION-TIME" type="xsd:double" minOccurs="0"/>
			<xsd:element name="MINIMAL-EXECUTION-TIME" type="xsd:double" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExecutionTime::MeasuredExecutionTime -->
	<xsd:complexType name="MEASURED-EXECUTION-TIME" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:EXECUTION-TIME"/>
			<xsd:group ref="AR:MEASURED-EXECUTION-TIME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ExecutionTime::MemorySectionLocation -->
	<xsd:group name="MEMORY-SECTION-LOCATION">
		<xsd:sequence>
			<xsd:element name="PROVIDED-MEMORY-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PROVIDED-MEMORY-SEGMENT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SOFTWARE-MEMORY-SECTION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OBJECT-FILE-SECTION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExecutionTime::MemorySectionLocation -->
	<xsd:complexType name="MEMORY-SECTION-LOCATION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:MEMORY-SECTION-LOCATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ExecutionTime::RoughEstimateOfExecutionTime -->
	<xsd:group name="ROUGH-ESTIMATE-OF-EXECUTION-TIME">
		<xsd:sequence>
			<xsd:element name="DESCRIPTION" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExecutionTime::RoughEstimateOfExecutionTime -->
	<xsd:complexType name="ROUGH-ESTIMATE-OF-EXECUTION-TIME" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:EXECUTION-TIME"/>
			<xsd:group ref="AR:ROUGH-ESTIMATE-OF-EXECUTION-TIME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ExecutionTime::SimulatedExecutionTime -->
	<xsd:group name="SIMULATED-EXECUTION-TIME">
		<xsd:sequence>
			<xsd:element name="AVERAGE-EXECUTION-TIME" type="xsd:double" minOccurs="0"/>
			<xsd:element name="MAXIMAL-EXECUTION-TIME" type="xsd:double" minOccurs="0"/>
			<xsd:element name="MINIMAL-EXECUTION-TIME" type="xsd:double" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExecutionTime::SimulatedExecutionTime -->
	<xsd:complexType name="SIMULATED-EXECUTION-TIME" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:EXECUTION-TIME"/>
			<xsd:group ref="AR:SIMULATED-EXECUTION-TIME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ExecutionTime::SoftwareContext -->
	<xsd:group name="SOFTWARE-CONTEXT">
		<xsd:sequence>
			<xsd:element name="INPUT" type="xsd:string" minOccurs="0"/>
			<xsd:element name="STATE" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExecutionTime::SoftwareContext -->
	<xsd:complexType name="SOFTWARE-CONTEXT" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SOFTWARE-CONTEXT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ExecutionTime::WorstCaseExecutionTime -->
	<xsd:group name="WORST-CASE-EXECUTION-TIME">
		<xsd:sequence>
			<xsd:element name="MAXIMAL-EXECUTION-TIME" type="xsd:double" minOccurs="0"/>
			<xsd:element name="MINIMAL-EXECUTION-TIME" type="xsd:double" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExecutionTime::WorstCaseExecutionTime -->
	<xsd:complexType name="WORST-CASE-EXECUTION-TIME" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:EXECUTION-TIME"/>
			<xsd:group ref="AR:WORST-CASE-EXECUTION-TIME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ExecutionTime::ExecutionTime -->
	<xsd:group name="EXECUTION-TIME">
		<xsd:sequence>
			<xsd:element name="ECU" type="AR:ECU-PROTOTYPE" minOccurs="0"/>
			<xsd:element name="EXCLUSIVE-AREA-SECTION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:RUNNABLE-ENTITY-CAN-ENTER-EXCLUSIVE-AREA--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="EXTERNAL-LIBRARY-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="EXTERNAL-LIBRARY-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:DEPENDENCY-ON-LIBRARY--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="HARDWARE-CONFIGURATION" type="AR:HARDWARE-CONFIGURATION" minOccurs="0"/>
			<xsd:element name="MEMORY-SECTION-LOCATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MEMORY-SECTION-LOCATION" type="AR:MEMORY-SECTION-LOCATION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RUNNABLE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:RUNNABLE-ENTITY--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SOFTWARE-CONTEXT" type="AR:SOFTWARE-CONTEXT" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExecutionTime::ExecutionTime -->
	<xsd:complexType name="EXECUTION-TIME" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:EXECUTION-TIME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class StackUsage::MeasuredStackUsage -->
	<xsd:group name="MEASURED-STACK-USAGE">
		<xsd:annotation>
			<xsd:documentation>
			The stack usage has been measured.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="AVERAGE-MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The average stack usage measured.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAXIMUM-MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maximum stack usage measured.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MINIMUM-MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The minimum stack usage measured.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TEST-PATTERN" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Description of the test pattern used to aquire the measured values.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class StackUsage::MeasuredStackUsage -->
	<xsd:complexType name="MEASURED-STACK-USAGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The stack usage has been measured.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:STACK-USAGE"/>
			<xsd:group ref="AR:MEASURED-STACK-USAGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class StackUsage::RoughEstimateStackUsage -->
	<xsd:group name="ROUGH-ESTIMATE-STACK-USAGE">
		<xsd:annotation>
			<xsd:documentation>
			Rough estimation of the stack usage.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Rough estimate of the stack usage.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class StackUsage::RoughEstimateStackUsage -->
	<xsd:complexType name="ROUGH-ESTIMATE-STACK-USAGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Rough estimation of the stack usage.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:STACK-USAGE"/>
			<xsd:group ref="AR:ROUGH-ESTIMATE-STACK-USAGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class StackUsage::WorstCaseStackUsage -->
	<xsd:group name="WORST-CASE-STACK-USAGE">
		<xsd:annotation>
			<xsd:documentation>
			Provides a formal worst case stack usage.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Worst case stack consumption.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class StackUsage::WorstCaseStackUsage -->
	<xsd:complexType name="WORST-CASE-STACK-USAGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Provides a formal worst case stack usage.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:STACK-USAGE"/>
			<xsd:group ref="AR:WORST-CASE-STACK-USAGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class StackUsage::StackUsage -->
	<xsd:group name="STACK-USAGE">
		<xsd:annotation>
			<xsd:documentation>
			Describes the stack memory usage of a software component
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ECU-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="HARDWARE-CONFIGURATION" type="AR:HARDWARE-CONFIGURATION" minOccurs="0"/>
			<xsd:element name="RUNNABLE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:RUNNABLE-ENTITY--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SOFTWARE-CONTEXT" type="AR:SOFTWARE-CONTEXT" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class HeapUsage::MeasuredHeapUsage -->
	<xsd:group name="MEASURED-HEAP-USAGE">
		<xsd:annotation>
			<xsd:documentation>
			The heap usage has been measured.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="AVERAGE-MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The average heap usage measured.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAXIMUM-MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maximum heap usage measured.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MINIMUM-MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The minimum heap usage measured.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TEST-PATTERN" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Description of the test pattern used to aquire the measured values.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class HeapUsage::MeasuredHeapUsage -->
	<xsd:complexType name="MEASURED-HEAP-USAGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The heap usage has been measured.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:HEAP-USAGE"/>
			<xsd:group ref="AR:MEASURED-HEAP-USAGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class HeapUsage::RoughEstimateHeapUsage -->
	<xsd:group name="ROUGH-ESTIMATE-HEAP-USAGE">
		<xsd:annotation>
			<xsd:documentation>
			Rough estimation of the heap usage.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Rough estimate of the heap usage.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class HeapUsage::RoughEstimateHeapUsage -->
	<xsd:complexType name="ROUGH-ESTIMATE-HEAP-USAGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Rough estimation of the heap usage.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:HEAP-USAGE"/>
			<xsd:group ref="AR:ROUGH-ESTIMATE-HEAP-USAGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class HeapUsage::WorstCaseHeapUsage -->
	<xsd:group name="WORST-CASE-HEAP-USAGE">
		<xsd:annotation>
			<xsd:documentation>
			Provides a formal worst case heap usage.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MEMORY-CONSUMPTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Worst case heap consumption.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class HeapUsage::WorstCaseHeapUsage -->
	<xsd:complexType name="WORST-CASE-HEAP-USAGE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Provides a formal worst case heap usage.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:HEAP-USAGE"/>
			<xsd:group ref="AR:WORST-CASE-HEAP-USAGE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class HeapUsage::HeapUsage -->
	<xsd:group name="HEAP-USAGE">
		<xsd:annotation>
			<xsd:documentation>
			Describes the heap memory usage of a SW-Component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ECU-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="HARDWARE-CONFIGURATION" type="AR:HARDWARE-CONFIGURATION" minOccurs="0"/>
			<xsd:element name="SOFTWARE-CONTEXT" type="AR:SOFTWARE-CONTEXT" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class InternalBehavior::InternalBehavior -->
	<xsd:group name="INTERNAL-BEHAVIOR">
		<xsd:annotation>
			<xsd:documentation>
			The internal behavior of an atomic software component describes the RTE relevant aspects of a component, i.e. the runnable entities and the events they respond to.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMPONENT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ATOMIC-SOFTWARE-COMPONENT-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="EVENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT" type="AR:ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT"/>
						<xsd:element name="DATA-RECEIVE-ERROR-EVENT" type="AR:DATA-RECEIVE-ERROR-EVENT"/>
						<xsd:element name="DATA-RECEIVED-EVENT" type="AR:DATA-RECEIVED-EVENT"/>
						<xsd:element name="DATA-SEND-COMPLETED-EVENT" type="AR:DATA-SEND-COMPLETED-EVENT"/>
						<xsd:element name="MODE-SWITCH-EVENT" type="AR:MODE-SWITCH-EVENT"/>
						<xsd:element name="MODE-SWITCHED-ACK-EVENT" type="AR:MODE-SWITCHED-ACK-EVENT"/>
						<xsd:element name="OPERATION-INVOKED-EVENT" type="AR:OPERATION-INVOKED-EVENT"/>
						<xsd:element name="TIMING-EVENT" type="AR:TIMING-EVENT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="EXCLUSIVE-AREAS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="EXCLUSIVE-AREA" type="AR:EXCLUSIVE-AREA"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="INTER-RUNNABLE-VARIABLES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="INTER-RUNNABLE-VARIABLE" type="AR:INTER-RUNNABLE-VARIABLE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="NVRAM-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="NVRAM-MAPPING" type="AR:NVRAM-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PER-INSTANCE-CALPRMS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CALPRM-ELEMENT-PROTOTYPE" type="AR:CALPRM-ELEMENT-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PER-INSTANCE-MEMORYS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PER-INSTANCE-MEMORY" type="AR:PER-INSTANCE-MEMORY"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-API-OPTIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PORT-API-OPTION" type="AR:PORT-API-OPTION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RUNNABLES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="RUNNABLE-ENTITY" type="AR:RUNNABLE-ENTITY"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SHARED-CALPRMS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CALPRM-ELEMENT-PROTOTYPE" type="AR:CALPRM-ELEMENT-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SUPPORTS-MULTIPLE-INSTANTIATION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Flag, whether the component can be multiply instantiated. which will result in an appropriate component API on programming language level (with or without instance handle).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class InternalBehavior::InternalBehavior -->
	<xsd:complexType name="INTERNAL-BEHAVIOR" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The internal behavior of an atomic software component describes the RTE relevant aspects of a component, i.e. the runnable entities and the events they respond to.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:INTERNAL-BEHAVIOR"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="INTERNAL-BEHAVIOR--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="INTERNAL-BEHAVIOR"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class InternalBehavior::RunnableEntity -->
	<xsd:group name="RUNNABLE-ENTITY">
		<xsd:annotation>
			<xsd:documentation>
			The runnable entities are the smallest code-fragments that are provided by the component and are executed in the RTE. Runnables are for instance set up to respond to data reception or operation invocation on a server.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CALPRM-ACCESSS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CALPRM-ACCESS" type="AR:CALPRM-ACCESS"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CAN-BE-INVOKED-CONCURRENTLY" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Normally, this is FALSE.
When this is TRUE, it is allowed that this runnable entity is invoked concurrently (even for one instance of the SW-C), which implies that it is the responsibility of the implementation of the runnable to take care of this form of concurrency.

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DATA-READ-ACCESSS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DATA-READ-ACCESS" type="AR:DATA-READ-ACCESS"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-RECEIVE-POINTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DATA-RECEIVE-POINT" type="AR:DATA-RECEIVE-POINT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-SEND-POINTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DATA-SEND-POINT" type="AR:DATA-SEND-POINT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-WRITE-ACCESSS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DATA-WRITE-ACCESS" type="AR:DATA-WRITE-ACCESS"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="INSIDE-EXCLUSIVE-AREAS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="RUNNABLE-ENTITY-RUNS-IN-EXCLUSIVE-AREA" type="AR:RUNNABLE-ENTITY-RUNS-IN-EXCLUSIVE-AREA"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MINIMUM-START-INTERVAL" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies the time in seconds which two starts of a RunnableEntity are guaranteed to be separated.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MODE-SWITCH-POINTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MODE-SWITCH-POINT" type="AR:MODE-SWITCH-POINT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PER-INSTANCE-CALPRM-ACCESS-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PER-INSTANCE-CALPRM-ACCESS-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:CALPRM-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="READ-VARIABLE-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="READ-VARIABLE-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:INTER-RUNNABLE-VARIABLE--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SERVER-CALL-POINTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ASYNCHRONOUS-SERVER-CALL-POINT" type="AR:ASYNCHRONOUS-SERVER-CALL-POINT"/>
						<xsd:element name="SYNCHRONOUS-SERVER-CALL-POINT" type="AR:SYNCHRONOUS-SERVER-CALL-POINT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SHARED-CALPRM-ACCESS-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SHARED-CALPRM-ACCESS-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:CALPRM-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SYMBOL" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The symbol describing this runnable&apos;s entry point. This is considered the API of the runnable and is required during the RTE contract phase.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="USES-EXCLUSIVE-AREAS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="RUNNABLE-ENTITY-CAN-ENTER-EXCLUSIVE-AREA" type="AR:RUNNABLE-ENTITY-CAN-ENTER-EXCLUSIVE-AREA"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="WAIT-POINTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="WAIT-POINT" type="AR:WAIT-POINT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="WRITTEN-VARIABLE-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="WRITTEN-VARIABLE-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:INTER-RUNNABLE-VARIABLE--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class InternalBehavior::RunnableEntity -->
	<xsd:complexType name="RUNNABLE-ENTITY" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The runnable entities are the smallest code-fragments that are provided by the component and are executed in the RTE. Runnables are for instance set up to respond to data reception or operation invocation on a server.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RUNNABLE-ENTITY"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="RUNNABLE-ENTITY--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="RUNNABLE-ENTITY"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class PortAPIOptions::PortAPIOption -->
	<xsd:group name="PORT-API-OPTION">
		<xsd:annotation>
			<xsd:documentation>
			Options how to generated the signatures of calls for an atomic SWC type in order to communicate over a port (for calls into a runable as well as for calls from a runnable to the port).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="INDIRECT-API" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			true: Specifies an &quot;indirect API&quot; to be generated for the associated port, which means that the SWC is able to access the actions on a port via a pointer to an object representing a port. This allows e.g. iterating over ports in a loop. This option has no effect for PPorts of client/server interfaces.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PORT-ARG-VALUES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="BOOLEAN-LITERAL" type="AR:BOOLEAN-LITERAL"/>
						<xsd:element name="CHAR-LITERAL" type="AR:CHAR-LITERAL"/>
						<xsd:element name="INTEGER-LITERAL" type="AR:INTEGER-LITERAL"/>
						<xsd:element name="OPAQUE-LITERAL" type="AR:OPAQUE-LITERAL"/>
						<xsd:element name="REAL-LITERAL" type="AR:REAL-LITERAL"/>
						<xsd:element name="STRING-LITERAL" type="AR:STRING-LITERAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PortAPIOptions::PortAPIOption -->
	<xsd:complexType name="PORT-API-OPTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Options how to generated the signatures of calls for an atomic SWC type in order to communicate over a port (for calls into a runable as well as for calls from a runnable to the port).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PORT-API-OPTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ExclusiveArea::RunnableEntityCanEnterExclusiveArea -->
	<xsd:group name="RUNNABLE-ENTITY-CAN-ENTER-EXCLUSIVE-AREA">
		<xsd:annotation>
			<xsd:documentation>
			This means that the runnable can enter/leave the referenced exclusive area through explicit API calls.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="EXCLUSIVE-AREA-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:EXCLUSIVE-AREA--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExclusiveArea::RunnableEntityCanEnterExclusiveArea -->
	<xsd:complexType name="RUNNABLE-ENTITY-CAN-ENTER-EXCLUSIVE-AREA" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This means that the runnable can enter/leave the referenced exclusive area through explicit API calls.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:RUNNABLE-ENTITY-CAN-ENTER-EXCLUSIVE-AREA"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="RUNNABLE-ENTITY-CAN-ENTER-EXCLUSIVE-AREA--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="RUNNABLE-ENTITY-CAN-ENTER-EXCLUSIVE-AREA"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ExclusiveArea::RunnableEntityRunsInExclusiveArea -->
	<xsd:group name="RUNNABLE-ENTITY-RUNS-IN-EXCLUSIVE-AREA">
		<xsd:annotation>
			<xsd:documentation>
			The runnable entity runs inside the referenced exclusive area

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="EXCLUSIVE-AREA-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:EXCLUSIVE-AREA--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ExclusiveArea::RunnableEntityRunsInExclusiveArea -->
	<xsd:complexType name="RUNNABLE-ENTITY-RUNS-IN-EXCLUSIVE-AREA" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The runnable entity runs inside the referenced exclusive area

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:RUNNABLE-ENTITY-RUNS-IN-EXCLUSIVE-AREA"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ExclusiveArea::ExclusiveArea -->
	<xsd:complexType name="EXCLUSIVE-AREA" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Prevent runnables from being preempted by other runnables.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="EXCLUSIVE-AREA--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="EXCLUSIVE-AREA"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class NVRAMMapping::NVRAMMapping -->
	<xsd:group name="NVRAM-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			Specifies all mappings concerning a single NVRAM block owned by an SWC instance. Note that the mapping is the same for all instances of an SWC type. For details see documentation of the associations.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFAULT-BLOCK-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CALPRM-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MIRROR-BLOCK-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PER-INSTANCE-MEMORY--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="NVRAM-NOTIFICATION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:P-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="NVRAM-PORT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class NVRAMMapping::NVRAMMapping -->
	<xsd:complexType name="NVRAM-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specifies all mappings concerning a single NVRAM block owned by an SWC instance. Note that the mapping is the same for all instances of an SWC type. For details see documentation of the associations.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:NVRAM-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::ModeSwitchedAckEvent -->
	<xsd:group name="MODE-SWITCHED-ACK-EVENT">
		<xsd:annotation>
			<xsd:documentation>
			The event is raised when the referenced mode have been received or an error occurs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="EVENT-SOURCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODE-SWITCH-POINT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class RTEEvents::ModeSwitchedAckEvent -->
	<xsd:complexType name="MODE-SWITCHED-ACK-EVENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The event is raised when the referenced mode have been received or an error occurs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RTE-EVENT"/>
			<xsd:group ref="AR:MODE-SWITCHED-ACK-EVENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::AsynchronousServerCallReturnsEvent -->
	<xsd:group name="ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT">
		<xsd:annotation>
			<xsd:documentation>
			This event is raised when an asynchronous server call is finished.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="EVENT-SOURCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ASYNCHRONOUS-SERVER-CALL-POINT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class RTEEvents::AsynchronousServerCallReturnsEvent -->
	<xsd:complexType name="ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This event is raised when an asynchronous server call is finished.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RTE-EVENT"/>
			<xsd:group ref="AR:ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::DataSendCompletedEvent -->
	<xsd:group name="DATA-SEND-COMPLETED-EVENT">
		<xsd:annotation>
			<xsd:documentation>
			The event is raised when the referenced data elements have been sent or an error occurs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="EVENT-SOURCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-SEND-POINT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class RTEEvents::DataSendCompletedEvent -->
	<xsd:complexType name="DATA-SEND-COMPLETED-EVENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The event is raised when the referenced data elements have been sent or an error occurs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RTE-EVENT"/>
			<xsd:group ref="AR:DATA-SEND-COMPLETED-EVENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::DataReceivedEvent -->
	<xsd:group name="DATA-RECEIVED-EVENT">
		<xsd:annotation>
			<xsd:documentation>
			The event is raised when the referenced data elements are received.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-IREF" type="AR:DATA-RECEIVED-EVENT--DATA-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class RTEEvents::DataReceivedEvent -->
	<xsd:complexType name="DATA-RECEIVED-EVENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The event is raised when the referenced data elements are received.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RTE-EVENT"/>
			<xsd:group ref="AR:DATA-RECEIVED-EVENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::DataReceiveErrorEvent -->
	<xsd:group name="DATA-RECEIVE-ERROR-EVENT">
		<xsd:annotation>
			<xsd:documentation>
			This event is raised by the RTE when the Com layer detects and notifies an error concerning the reception of the referenced data element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-IREF" type="AR:DATA-RECEIVE-ERROR-EVENT--DATA-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class RTEEvents::DataReceiveErrorEvent -->
	<xsd:complexType name="DATA-RECEIVE-ERROR-EVENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This event is raised by the RTE when the Com layer detects and notifies an error concerning the reception of the referenced data element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RTE-EVENT"/>
			<xsd:group ref="AR:DATA-RECEIVE-ERROR-EVENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::TimingEvent -->
	<xsd:group name="TIMING-EVENT">
		<xsd:annotation>
			<xsd:documentation>
			TimingEvent references the runnable that need to be started in response to the TimingEvent
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PERIOD" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Period of timing event in seconds.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class RTEEvents::TimingEvent -->
	<xsd:complexType name="TIMING-EVENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			TimingEvent references the runnable that need to be started in response to the TimingEvent
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RTE-EVENT"/>
			<xsd:group ref="AR:TIMING-EVENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::OperationInvokedEvent -->
	<xsd:group name="OPERATION-INVOKED-EVENT">
		<xsd:annotation>
			<xsd:documentation>
			The OperationINvokedEvent references the operation invoked by the client.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OPERATION-IREF" type="AR:OPERATION-INVOKED-EVENT--OPERATION-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class RTEEvents::OperationInvokedEvent -->
	<xsd:complexType name="OPERATION-INVOKED-EVENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The OperationINvokedEvent references the operation invoked by the client.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RTE-EVENT"/>
			<xsd:group ref="AR:OPERATION-INVOKED-EVENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::WaitPoint -->
	<xsd:group name="WAIT-POINT">
		<xsd:annotation>
			<xsd:documentation>
			This defines a wait-point for which the runnable can wait.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="TIMEOUT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Time in seconds before the waitpoint times out and the blocking wait call returns with an error indicating the timeout.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TRIGGER-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="TRIGGER-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:RTE-EVENT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class RTEEvents::WaitPoint -->
	<xsd:complexType name="WAIT-POINT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This defines a wait-point for which the runnable can wait.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:WAIT-POINT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::ModeSwitchEvent -->
	<xsd:group name="MODE-SWITCH-EVENT">
		<xsd:annotation>
			<xsd:documentation>
			This event is listening to mode changes coming from the StateManager.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTIVATION" type="AR:MODE-ACTIVATION-KIND" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies if the event is activated on entering or exiting the referenced Mode.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MODE-IREF" type="AR:MODE-SWITCH-EVENT--MODE-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class RTEEvents::ModeSwitchEvent -->
	<xsd:complexType name="MODE-SWITCH-EVENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This event is listening to mode changes coming from the StateManager.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:RTE-EVENT"/>
			<xsd:group ref="AR:MODE-SWITCH-EVENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class RTEEvents::RTEEvent -->
	<xsd:group name="RTE-EVENT">
		<xsd:annotation>
			<xsd:documentation>
			Abstract base class for all RTE-related events
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MODE-DEPENDENCY" type="AR:MODE-DISABLING-DEPENDENCY" minOccurs="0"/>
			<xsd:element name="START-ON-EVENT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:RUNNABLE-ENTITY--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="RTE-EVENT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT"/>
			<xsd:enumeration value="DATA-RECEIVE-ERROR-EVENT"/>
			<xsd:enumeration value="DATA-RECEIVED-EVENT"/>
			<xsd:enumeration value="DATA-SEND-COMPLETED-EVENT"/>
			<xsd:enumeration value="MODE-SWITCH-EVENT"/>
			<xsd:enumeration value="MODE-SWITCHED-ACK-EVENT"/>
			<xsd:enumeration value="OPERATION-INVOKED-EVENT"/>
			<xsd:enumeration value="TIMING-EVENT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class _instanceRef::DataReceivedEvent_data -->
	<xsd:group name="DATA-RECEIVED-EVENT--DATA-IREF">
		<xsd:sequence>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::DataReceivedEvent_data -->
	<xsd:complexType name="DATA-RECEIVED-EVENT--DATA-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DATA-RECEIVED-EVENT--DATA-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::DataReceiveErrorEvent_data -->
	<xsd:group name="DATA-RECEIVE-ERROR-EVENT--DATA-IREF">
		<xsd:sequence>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::DataReceiveErrorEvent_data -->
	<xsd:complexType name="DATA-RECEIVE-ERROR-EVENT--DATA-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DATA-RECEIVE-ERROR-EVENT--DATA-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ModeSwitchEvent_mode -->
	<xsd:group name="MODE-SWITCH-EVENT--MODE-IREF">
		<xsd:sequence>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODE-DECLARATION-GROUP-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODE-DECLARATION-GROUP-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODE-DECLARATION-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODE-DECLARATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ModeSwitchEvent_mode -->
	<xsd:complexType name="MODE-SWITCH-EVENT--MODE-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:MODE-SWITCH-EVENT--MODE-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::OperationInvokedEvent_operation -->
	<xsd:group name="OPERATION-INVOKED-EVENT--OPERATION-IREF">
		<xsd:sequence>
			<xsd:element name="P-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:P-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OPERATION-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OPERATION-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::OperationInvokedEvent_operation -->
	<xsd:complexType name="OPERATION-INVOKED-EVENT--OPERATION-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:OPERATION-INVOKED-EVENT--OPERATION-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ModeDeclarationGroup::ModeSwitchPoint -->
	<xsd:group name="MODE-SWITCH-POINT">
		<xsd:annotation>
			<xsd:documentation>
			A mode switch point specifies that a runnable explicitly received a certain mode.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MODE-GROUP-IREF" type="AR:MODE-SWITCH-POINT--MODE-GROUP-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ModeDeclarationGroup::ModeSwitchPoint -->
	<xsd:complexType name="MODE-SWITCH-POINT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A mode switch point specifies that a runnable explicitly received a certain mode.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:MODE-SWITCH-POINT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="MODE-SWITCH-POINT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MODE-SWITCH-POINT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class _instanceRef::ModeSwitchPoint_modeGroup -->
	<xsd:group name="MODE-SWITCH-POINT--MODE-GROUP-IREF">
		<xsd:sequence>
			<xsd:element name="P-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:P-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODE-DECLARATION-GROUP-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODE-DECLARATION-GROUP-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ModeSwitchPoint_modeGroup -->
	<xsd:complexType name="MODE-SWITCH-POINT--MODE-GROUP-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:MODE-SWITCH-POINT--MODE-GROUP-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ServerCall::ServerCallPoint -->
	<xsd:group name="SERVER-CALL-POINT">
		<xsd:annotation>
			<xsd:documentation>
			When a runnable has a serverCallPoint, it has the possibility to invoke any of the operations of a specific rport of the component.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OPERATION-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="OPERATION-IREF" type="AR:SERVER-CALL-POINT--OPERATION-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="TIMEOUT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Time in seconds before the server call times out and returns with an error message. It depends on the call type (synchronous or asynchronous) how this is reported.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ServerCall::SynchronousServerCallPoint -->
	<xsd:complexType name="SYNCHRONOUS-SERVER-CALL-POINT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This means that the runnable will block for a response from the server.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SERVER-CALL-POINT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ServerCall::AsynchronousServerCallPoint -->
	<xsd:complexType name="ASYNCHRONOUS-SERVER-CALL-POINT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An asynchronous server call-point is used for asynchronous invocation of an operation prototype. It is associated with AsynchronousServerCallReturnsEvent, this RTEEvent notifies the completion of the required operation or a timeout, this event can be waited for or it can lead to the invocation of a runnable. 
IMPORTANT: a server-call-point cannot be used concurrently. Once the client runnable has made the invocation, the server-call-point cannot be used until the call returns (or an error occurs!) at which point the server call-point becomes available again...

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SERVER-CALL-POINT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ASYNCHRONOUS-SERVER-CALL-POINT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ASYNCHRONOUS-SERVER-CALL-POINT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class _instanceRef::ServerCallPoint_operation -->
	<xsd:group name="SERVER-CALL-POINT--OPERATION-IREF">
		<xsd:sequence>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OPERATION-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OPERATION-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ServerCallPoint_operation -->
	<xsd:complexType name="SERVER-CALL-POINT--OPERATION-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SERVER-CALL-POINT--OPERATION-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataElements::DataReceivePoint -->
	<xsd:group name="DATA-RECEIVE-POINT">
		<xsd:annotation>
			<xsd:documentation>
			A data receive point allows a runnable to explicitly query for received information, thereby blocking write access to the same information only for a very brief period.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREF" type="AR:DATA-RECEIVE-POINT--DATA-ELEMENT-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataElements::DataReceivePoint -->
	<xsd:complexType name="DATA-RECEIVE-POINT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A data receive point allows a runnable to explicitly query for received information, thereby blocking write access to the same information only for a very brief period.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-RECEIVE-POINT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class DataElements::DataReadAccess -->
	<xsd:group name="DATA-READ-ACCESS">
		<xsd:annotation>
			<xsd:documentation>
			The presences of a DataReadAccess means that the runnable needs access to the DataElement in the rPort. The runnable will not modify the contents of the data but only read the information.
The runnable expects that the contents of this data does NOT change during its entire execution.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREF" type="AR:DATA-READ-ACCESS--DATA-ELEMENT-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataElements::DataReadAccess -->
	<xsd:complexType name="DATA-READ-ACCESS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The presences of a DataReadAccess means that the runnable needs access to the DataElement in the rPort. The runnable will not modify the contents of the data but only read the information.
The runnable expects that the contents of this data does NOT change during its entire execution.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-READ-ACCESS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class DataElements::DataWriteAccess -->
	<xsd:group name="DATA-WRITE-ACCESS">
		<xsd:annotation>
			<xsd:documentation>
			The presences of a DataWriteAccess means that the runnable will potentially modify the dataElement in the pPort. The runnable has free access to the data-element while it is running. The runnable has the responsibility to make sure that the data-element is in a consistent state when it returns. When using DataWriteAccess the new values of the data-element is not made available via the communication infrastrucure before the runnable returns (exits the &quot;Running&quot; state).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREF" type="AR:DATA-WRITE-ACCESS--DATA-ELEMENT-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataElements::DataWriteAccess -->
	<xsd:complexType name="DATA-WRITE-ACCESS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The presences of a DataWriteAccess means that the runnable will potentially modify the dataElement in the pPort. The runnable has free access to the data-element while it is running. The runnable has the responsibility to make sure that the data-element is in a consistent state when it returns. When using DataWriteAccess the new values of the data-element is not made available via the communication infrastrucure before the runnable returns (exits the &quot;Running&quot; state).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-WRITE-ACCESS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class DataElements::DataSendPoint -->
	<xsd:group name="DATA-SEND-POINT">
		<xsd:annotation>
			<xsd:documentation>
			A data send point specifies that a runnable explicitly sends a certain data element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREF" type="AR:DATA-SEND-POINT--DATA-ELEMENT-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataElements::DataSendPoint -->
	<xsd:complexType name="DATA-SEND-POINT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A data send point specifies that a runnable explicitly sends a certain data element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-SEND-POINT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="DATA-SEND-POINT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="DATA-SEND-POINT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class _instanceRef::DataReadAccess_dataElement -->
	<xsd:group name="DATA-READ-ACCESS--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::DataReadAccess_dataElement -->
	<xsd:complexType name="DATA-READ-ACCESS--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DATA-READ-ACCESS--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::DataReceivePoint_dataElement -->
	<xsd:group name="DATA-RECEIVE-POINT--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="R-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:R-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::DataReceivePoint_dataElement -->
	<xsd:complexType name="DATA-RECEIVE-POINT--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DATA-RECEIVE-POINT--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::DataSendPoint_dataElement -->
	<xsd:group name="DATA-SEND-POINT--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="P-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:P-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::DataSendPoint_dataElement -->
	<xsd:complexType name="DATA-SEND-POINT--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DATA-SEND-POINT--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::DataWriteAccess_dataElement -->
	<xsd:group name="DATA-WRITE-ACCESS--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="P-PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:P-PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::DataWriteAccess_dataElement -->
	<xsd:complexType name="DATA-WRITE-ACCESS--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:DATA-WRITE-ACCESS--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="COMMUNICATION-APPROACH-TYPE">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="IMPLICIT"/>
			<xsd:enumeration value="EXPLICIT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class InterRunnableCommunication::InterRunnableVariable -->
	<xsd:group name="INTER-RUNNABLE-VARIABLE">
		<xsd:annotation>
			<xsd:documentation>
			Implement state message semantics for establishing communication among runnables of the same component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-APPROACH" type="AR:COMMUNICATION-APPROACH-TYPE" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Communication among RunnableEntities resembles the approaches taken for the communication among software components. The explicit communication corresponds to DataReceivePoint/DataSendPoint. The implicit communication resembles DataReadAccess/DataWriteAccess
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="INIT-VALUE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:VALUE-SPECIFICATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MEASURABLE" type="AR:MEASURABLE" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class InterRunnableCommunication::InterRunnableVariable -->
	<xsd:complexType name="INTER-RUNNABLE-VARIABLE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Implement state message semantics for establishing communication among runnables of the same component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DATA-PROTOTYPE"/>
			<xsd:group ref="AR:INTER-RUNNABLE-VARIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="INTER-RUNNABLE-VARIABLE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="INTER-RUNNABLE-VARIABLE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class PerInstanceMemory::PerInstanceMemory -->
	<xsd:group name="PER-INSTANCE-MEMORY">
		<xsd:annotation>
			<xsd:documentation>
			Defines a memory-block that needs to be available for each instance of the SW-component.  This is typically only useful when supportsMultipleInstantiation is TRUE.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="TYPE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The &quot;C&quot;-type
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TYPE-DEFINITION" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			A definition of the type
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PerInstanceMemory::PerInstanceMemory -->
	<xsd:complexType name="PER-INSTANCE-MEMORY" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Defines a memory-block that needs to be available for each instance of the SW-component.  This is typically only useful when supportsMultipleInstantiation is TRUE.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PER-INSTANCE-MEMORY"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="PER-INSTANCE-MEMORY--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PER-INSTANCE-MEMORY"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Implementation::Code -->
	<xsd:group name="CODE">
		<xsd:annotation>
			<xsd:documentation>
			A generic code descriptor.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="TYPE" type="AR:CODE-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The type of described code.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="XFILES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="XFILE" type="AR:XFILE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Implementation::Code -->
	<xsd:complexType name="CODE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A generic code descriptor.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:CODE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="CODE-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SRC"/>
			<xsd:enumeration value="OBJ"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Implementation::Compiler -->
	<xsd:group name="COMPILER">
		<xsd:sequence>
			<xsd:element name="NAME" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Compiler name (like gcc).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="VENDOR" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Vendor of compiler.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="VERSION" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Exact version of compiler executable.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Implementation::Compiler -->
	<xsd:complexType name="COMPILER" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMPILER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Implementation::Dependency -->
	<xsd:group name="DEPENDENCY">
		<xsd:annotation>
			<xsd:documentation>
			General dependency, typically on the existence of another artifact.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="USAGE" type="AR:DEPENDENCY-USAGE-ENUM" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			Specification during for which process step(s) this dependency is required.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="DEPENDENCY-USAGE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMPILE"/>
			<xsd:enumeration value="LINK"/>
			<xsd:enumeration value="BUILD"/>
			<xsd:enumeration value="EXECUTE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Implementation::DependencyOnFile -->
	<xsd:group name="DEPENDENCY-ON-FILE">
		<xsd:annotation>
			<xsd:documentation>
			Dependency on the existence of a certain file.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="XFILE" type="AR:XFILE" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Implementation::DependencyOnFile -->
	<xsd:complexType name="DEPENDENCY-ON-FILE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Dependency on the existence of a certain file.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DEPENDENCY"/>
			<xsd:group ref="AR:DEPENDENCY-ON-FILE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Implementation::Implementation -->
	<xsd:group name="IMPLEMENTATION">
		<xsd:annotation>
			<xsd:documentation>
			Description of an implementation for a single atomic software component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BEHAVIOR-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:INTERNAL-BEHAVIOR--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CODE-DESCRIPTOR" type="AR:CODE" minOccurs="0"/>
			<xsd:element name="CODE-GENERATOR" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Optional: code generator used.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="COMPILERS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMPILER" type="AR:COMPILER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="IMPLEMENTATION-DEPENDENCIES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DEPENDENCY-ON-FILE" type="AR:DEPENDENCY-ON-FILE"/>
						<xsd:element name="DEPENDENCY-ON-LIBRARY" type="AR:DEPENDENCY-ON-LIBRARY"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROCESSOR-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PROCESSOR-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:PROCESSING-UNIT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROGRAMMING-LANGUAGE" type="AR:IMPLEMENTATION-PROGRAMMING-LANGUAGE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Programming language the implementation was created in.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="REQUIRED-RTE-VENDOR" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Identify a specific RTE vendor. This information is potentially important at the time of integrating (in particular: linking) the application code with the RTE. The semantics is that (if the association exists) the corresponding code has been created to fit to the vendor-mode RTE provided by this specific vendor. Attempting to integrate the code with another RTE generated in vendor mode is in general not possible.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RESOURCE-CONSUMPTION" type="AR:RESOURCE-CONSUMPTION" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Implementation::Implementation -->
	<xsd:complexType name="IMPLEMENTATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Description of an implementation for a single atomic software component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:IMPLEMENTATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="IMPLEMENTATION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="IMPLEMENTATION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="IMPLEMENTATION-PROGRAMMING-LANGUAGE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="C"/>
			<xsd:enumeration value="CPP"/>
			<xsd:enumeration value="JAVA"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Implementation::DependencyOnLibrary -->
	<xsd:group name="DEPENDENCY-ON-LIBRARY">
		<xsd:annotation>
			<xsd:documentation>
			A specific file dependency: without the library that implementation cannot be used (compiled, linked, executed, ...).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MAX-VERSION" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum version compatible with implementation. If not set, there is limitation on the upper version.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN-VERSION" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Minimum version compatible with implementation.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Implementation::DependencyOnLibrary -->
	<xsd:complexType name="DEPENDENCY-ON-LIBRARY" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A specific file dependency: without the library that implementation cannot be used (compiled, linked, executed, ...).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:DEPENDENCY"/>
			<xsd:group ref="AR:DEPENDENCY-ON-FILE"/>
			<xsd:group ref="AR:DEPENDENCY-ON-LIBRARY"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="DEPENDENCY-ON-LIBRARY--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="DEPENDENCY-ON-LIBRARY"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Services::EcuSwComposition -->
	<xsd:group name="ECU-SW-COMPOSITION">
		<xsd:annotation>
			<xsd:documentation>
			EcuSwComposition contains the complete Software Composition in an ECU, consisting both of application software components and service components.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMPONENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SERVICE-COMPONENT-PROTOTYPE" type="AR:SERVICE-COMPONENT-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CONNECTORS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SERVICE-CONNECTOR-PROTOTYPE" type="AR:SERVICE-CONNECTOR-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-EXTRACT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Services::EcuSwComposition -->
	<xsd:complexType name="ECU-SW-COMPOSITION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			EcuSwComposition contains the complete Software Composition in an ECU, consisting both of application software components and service components.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:ECU-SW-COMPOSITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ECU-SW-COMPOSITION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ECU-SW-COMPOSITION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Services::ServiceComponentPrototype -->
	<xsd:group name="SERVICE-COMPONENT-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			Each service in an ECU is represented by exactly one ServiceComponentPrototype. Instances of this class are only to be created in ECU Configuration phase for the specific purpose of the service configuration.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SERVICE-COMPONENT-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SERVICE-COMPONENT-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Services::ServiceComponentPrototype -->
	<xsd:complexType name="SERVICE-COMPONENT-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Each service in an ECU is represented by exactly one ServiceComponentPrototype. Instances of this class are only to be created in ECU Configuration phase for the specific purpose of the service configuration.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SERVICE-COMPONENT-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SERVICE-COMPONENT-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SERVICE-COMPONENT-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Components::PPortPrototype -->
	<xsd:group name="P-PORT-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			Component port providing a certain port interface.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PROVIDED-COM-SPECS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MODE-SWITCH-COM-SPEC" type="AR:MODE-SWITCH-COM-SPEC"/>
						<xsd:element name="QUEUED-SENDER-COM-SPEC" type="AR:QUEUED-SENDER-COM-SPEC"/>
						<xsd:element name="SERVER-COM-SPEC" type="AR:SERVER-COM-SPEC"/>
						<xsd:element name="UNQUEUED-SENDER-COM-SPEC" type="AR:UNQUEUED-SENDER-COM-SPEC"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROVIDED-INTERFACE-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-INTERFACE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Components::PPortPrototype -->
	<xsd:complexType name="P-PORT-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Component port providing a certain port interface.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PORT-PROTOTYPE"/>
			<xsd:group ref="AR:P-PORT-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="P-PORT-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="P-PORT-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Components::PortPrototype -->
	<xsd:group name="PORT-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			Base class for the ports of an AUTOSAR software component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ANNOTATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CALIBRATION-PORT-ANNOTATION" type="AR:CALIBRATION-PORT-ANNOTATION"/>
						<xsd:element name="COM-M-USER-NEEDS" type="AR:COM-M-USER-NEEDS"/>
						<xsd:element name="IO-HW-ABSTRACTION-SERVER-ANNOTATION" type="AR:IO-HW-ABSTRACTION-SERVER-ANNOTATION"/>
						<xsd:element name="NVRAM-BLOCK-NEEDS" type="AR:NVRAM-BLOCK-NEEDS"/>
						<xsd:element name="RECEIVER-ANNOTATION" type="AR:RECEIVER-ANNOTATION"/>
						<xsd:element name="SENDER-ANNOTATION" type="AR:SENDER-ANNOTATION"/>
						<xsd:element name="SERVICE-NEEDS" type="AR:SERVICE-NEEDS"/>
						<xsd:element name="SUPERVISED-ENTITY-NEEDS" type="AR:SUPERVISED-ENTITY-NEEDS"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="PORT-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="P-PORT-PROTOTYPE"/>
			<xsd:enumeration value="R-PORT-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Components::RPortPrototype -->
	<xsd:group name="R-PORT-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			Component port requiring a certain port interface.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="REQUIRED-COM-SPECS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLIENT-COM-SPEC" type="AR:CLIENT-COM-SPEC"/>
						<xsd:element name="QUEUED-RECEIVER-COM-SPEC" type="AR:QUEUED-RECEIVER-COM-SPEC"/>
						<xsd:element name="UNQUEUED-RECEIVER-COM-SPEC" type="AR:UNQUEUED-RECEIVER-COM-SPEC"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="REQUIRED-INTERFACE-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-INTERFACE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Components::RPortPrototype -->
	<xsd:complexType name="R-PORT-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Component port requiring a certain port interface.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PORT-PROTOTYPE"/>
			<xsd:group ref="AR:R-PORT-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="R-PORT-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="R-PORT-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Components::AtomicSoftwareComponentType -->
	<xsd:group name="ATOMIC-SOFTWARE-COMPONENT-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			An atomic software component is atomic in the sense that it cannot be further decomposed and distributed across multiple ECUs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MEASURABLES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MEASURABLE" type="AR:MEASURABLE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Components::AtomicSoftwareComponentType -->
	<xsd:complexType name="ATOMIC-SOFTWARE-COMPONENT-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An atomic software component is atomic in the sense that it cannot be further decomposed and distributed across multiple ECUs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMPONENT-TYPE"/>
			<xsd:group ref="AR:ATOMIC-SOFTWARE-COMPONENT-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ATOMIC-SOFTWARE-COMPONENT-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ATOMIC-SOFTWARE-COMPONENT-TYPE"/>
			<xsd:enumeration value="SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE"/>
			<xsd:enumeration value="SERVICE-COMPONENT-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Components::ServiceComponentType -->
	<xsd:complexType name="SERVICE-COMPONENT-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			ServiceComponentType is used for configuring services for a given ECU. Instances of this class are only to be created in ECU Configuration phase for the specific purpose of the service configuration.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMPONENT-TYPE"/>
			<xsd:group ref="AR:ATOMIC-SOFTWARE-COMPONENT-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SERVICE-COMPONENT-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SERVICE-COMPONENT-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Components::CalprmComponentType -->
	<xsd:complexType name="CALPRM-COMPONENT-TYPE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMPONENT-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Components::SensorActuatorSoftwareComponentType -->
	<xsd:group name="SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			The SensorActuatorSoftwareComponentType introduces the possibility to link from the software representation of a sensor/actuator to its hardware description provided by the ECU Resource Template.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SENSOR-ACTUATOR-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SENSOR-ACTUATOR-HW--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Components::SensorActuatorSoftwareComponentType -->
	<xsd:complexType name="SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The SensorActuatorSoftwareComponentType introduces the possibility to link from the software representation of a sensor/actuator to its hardware description provided by the ECU Resource Template.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMPONENT-TYPE"/>
			<xsd:group ref="AR:ATOMIC-SOFTWARE-COMPONENT-TYPE"/>
			<xsd:group ref="AR:SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Components::ComponentType -->
	<xsd:group name="COMPONENT-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			Base class for AUTOSAR software components.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PORTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="P-PORT-PROTOTYPE" type="AR:P-PORT-PROTOTYPE"/>
						<xsd:element name="R-PORT-PROTOTYPE" type="AR:R-PORT-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="COMPONENT-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ATOMIC-SOFTWARE-COMPONENT-TYPE"/>
			<xsd:enumeration value="CALPRM-COMPONENT-TYPE"/>
			<xsd:enumeration value="COMPOSITION-TYPE"/>
			<xsd:enumeration value="SENSOR-ACTUATOR-SOFTWARE-COMPONENT-TYPE"/>
			<xsd:enumeration value="SERVICE-COMPONENT-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SystemTemplate::SystemTopologyInstance -->
	<xsd:group name="SYSTEM-TOPOLOGY-INSTANCE">
		<xsd:annotation>
			<xsd:documentation>
			The topology of the system. Since several systems may share the same topology, a reference to a system topology type is used to define which topology is used in the system.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="TOPOLOGY-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemTemplate::SystemTopologyInstance -->
	<xsd:complexType name="SYSTEM-TOPOLOGY-INSTANCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The topology of the system. Since several systems may share the same topology, a reference to a system topology type is used to define which topology is used in the system.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SYSTEM-TOPOLOGY-INSTANCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SYSTEM-TOPOLOGY-INSTANCE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SystemTemplate::CommunicationMatrixInstance -->
	<xsd:group name="COMMUNICATION-MATRIX-INSTANCE">
		<xsd:annotation>
			<xsd:documentation>
			A communication matrix defines frames that are transported on a specific communication system, with timing etc. The CommunicationMatrixInstance references to the communicationMatrixType that shall be used in the system.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-MATRIX-TYPE-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMMUNICATION-MATRIX-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemTemplate::CommunicationMatrixInstance -->
	<xsd:complexType name="COMMUNICATION-MATRIX-INSTANCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A communication matrix defines frames that are transported on a specific communication system, with timing etc. The CommunicationMatrixInstance references to the communicationMatrixType that shall be used in the system.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMMUNICATION-MATRIX-INSTANCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMMUNICATION-MATRIX-INSTANCE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMMUNICATION-MATRIX-INSTANCE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SystemTemplate::GatewayInstance -->
	<xsd:group name="GATEWAY-INSTANCE">
		<xsd:annotation>
			<xsd:documentation>
			A gateway is a functionality within an ECU that performs a frame or signal mapping function between two or more communication clusters. The GatewayInstance references to the GatewayType used in the system.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="GATEWAY-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:GATEWAY-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemTemplate::GatewayInstance -->
	<xsd:complexType name="GATEWAY-INSTANCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A gateway is a functionality within an ECU that performs a frame or signal mapping function between two or more communication clusters. The GatewayInstance references to the GatewayType used in the system.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:GATEWAY-INSTANCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class SystemTemplate::System -->
	<xsd:group name="SYSTEM">
		<xsd:annotation>
			<xsd:documentation>
			System aggregates all elements that define a system constraint description or system configuration description.
System is a PropertyContainer since we want to model variants as properties. For each dimension of variability, one property is added. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMMUNICATION" type="AR:SYSTEM-COMMUNICATION" minOccurs="0"/>
			<xsd:element name="MAPPING" type="AR:SYSTEM-MAPPING" minOccurs="0"/>
			<xsd:element name="SOFTWARE-COMPOSITION" type="AR:SOFTWARE-COMPOSITION" minOccurs="0"/>
			<xsd:element name="TOPOLOGY" type="AR:SYSTEM-TOPOLOGY-INSTANCE" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemTemplate::System -->
	<xsd:complexType name="SYSTEM" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			System aggregates all elements that define a system constraint description or system configuration description.
System is a PropertyContainer since we want to model variants as properties. For each dimension of variability, one property is added. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SYSTEM"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SYSTEM--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SYSTEM"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SystemTemplate::SystemMapping -->
	<xsd:group name="SYSTEM-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			The system mapping aggregates all mapping aspects (mapping of SW components to ECUs, mapping of data elements to signals, and mapping constraints).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING" type="AR:CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING"/>
						<xsd:element name="SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING" type="AR:SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING"/>
						<xsd:element name="SENDER-RECEIVER-TO-SIGNAL-MAPPING" type="AR:SENDER-RECEIVER-TO-SIGNAL-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MAPPING-CONSTRAINTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMPONENT-CLUSTER" type="AR:COMPONENT-CLUSTER"/>
						<xsd:element name="COMPONENT-SEPARATION" type="AR:COMPONENT-SEPARATION"/>
						<xsd:element name="FREE-TEXT-MAPPING-CONSTRAINT" type="AR:FREE-TEXT-MAPPING-CONSTRAINT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RESOURCE-ESTIMATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ECU-RESOURCE-ESTIMATION" type="AR:ECU-RESOURCE-ESTIMATION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIGNAL-PATH-CONSTRAINTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMMON-SIGNAL-PATH" type="AR:COMMON-SIGNAL-PATH"/>
						<xsd:element name="FORBIDDEN-SIGNAL-PATH" type="AR:FORBIDDEN-SIGNAL-PATH"/>
						<xsd:element name="PERMISSIBLE-SIGNAL-PATH" type="AR:PERMISSIBLE-SIGNAL-PATH"/>
						<xsd:element name="SEPARATE-SIGNAL-PATH" type="AR:SEPARATE-SIGNAL-PATH"/>
						<xsd:element name="SIGNAL-PATH-CONSTRAINT" type="AR:SIGNAL-PATH-CONSTRAINT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-IMPL-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SW-COMP-TO-IMPL-MAPPING" type="AR:SW-COMP-TO-IMPL-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SW-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SW-COMP-TO-ECU-MAPPING" type="AR:SW-COMP-TO-ECU-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemTemplate::SystemMapping -->
	<xsd:complexType name="SYSTEM-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The system mapping aggregates all mapping aspects (mapping of SW components to ECUs, mapping of data elements to signals, and mapping constraints).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SYSTEM-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class SystemTemplate::SystemCommunication -->
	<xsd:group name="SYSTEM-COMMUNICATION">
		<xsd:annotation>
			<xsd:documentation>
			The system communication defines all frames exchanged on any communication cluster, and their relation among each other. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-MATRIXS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMMUNICATION-MATRIX-INSTANCE" type="AR:COMMUNICATION-MATRIX-INSTANCE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMMUNICATION-PROTOCOLS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMM-PROTOCOL-INSTANCE" type="AR:COMM-PROTOCOL-INSTANCE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="GATEWAYS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="GATEWAY-INSTANCE" type="AR:GATEWAY-INSTANCE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemTemplate::SystemCommunication -->
	<xsd:complexType name="SYSTEM-COMMUNICATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The system communication defines all frames exchanged on any communication cluster, and their relation among each other. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SYSTEM-COMMUNICATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SystemTemplate::SoftwareComposition -->
	<xsd:group name="SOFTWARE-COMPOSITION">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPOSITION-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemTemplate::SoftwareComposition -->
	<xsd:complexType name="SOFTWARE-COMPOSITION" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SOFTWARE-COMPOSITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SOFTWARE-COMPOSITION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SOFTWARE-COMPOSITION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::CommunicationMatrixType -->
	<xsd:group name="COMMUNICATION-MATRIX-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			A communication matrix defines frames that are transported on a specific communication system, with timing etc. The communication matrix is separated from the topology, since the same topology may be used with different communication matrices. The same communication matrix  type may be reused in different systems. Reuse is however only possible if the systems reuse the same topology (i.e. system topology type) as well.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-CLUSTER" type="AR:COMMUNICATION-MATRIX-TYPE-COMMUNICATION-CLUSTER" minOccurs="0"/>
			<xsd:element name="FRAMES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CAN-FRAME" type="AR:CAN-FRAME"/>
						<xsd:element name="FLEXRAY-FRAME" type="AR:FLEXRAY-FRAME"/>
						<xsd:element name="FRAME" type="AR:FRAME"/>
						<xsd:element name="LIN-FRAME" type="AR:LIN-FRAME"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="LIN-SCHEDULING-TABLES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="LIN-SCHEDULING-TABLE" type="AR:LIN-SCHEDULING-TABLE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SYSTEM-TOPOLOGY-TYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::CommunicationMatrixType -->
	<xsd:complexType name="COMMUNICATION-MATRIX-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A communication matrix defines frames that are transported on a specific communication system, with timing etc. The communication matrix is separated from the topology, since the same topology may be used with different communication matrices. The same communication matrix  type may be reused in different systems. Reuse is however only possible if the systems reuse the same topology (i.e. system topology type) as well.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMMUNICATION-MATRIX-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMMUNICATION-MATRIX-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMMUNICATION-MATRIX-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::LinSchedulingTable -->
	<xsd:group name="LIN-SCHEDULING-TABLE">
		<xsd:annotation>
			<xsd:documentation>
			The master task (in the master node) transmits frame headers based on a schedule table. The schedule table specifies the identifiers for each header and the interval
between the start of a frame and the start of the following frame. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ENTRIES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="EVENT-TRIGGERED-FRAME-SLOT" type="AR:EVENT-TRIGGERED-FRAME-SLOT"/>
						<xsd:element name="LIN-SCHEDULING-TABLE-ENTRY" type="AR:LIN-SCHEDULING-TABLE-ENTRY"/>
						<xsd:element name="SPORADIC-FRAME-SLOT" type="AR:SPORADIC-FRAME-SLOT"/>
						<xsd:element name="UNCONDITIONAL-FRAME-SLOT" type="AR:UNCONDITIONAL-FRAME-SLOT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::LinSchedulingTable -->
	<xsd:complexType name="LIN-SCHEDULING-TABLE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The master task (in the master node) transmits frame headers based on a schedule table. The schedule table specifies the identifiers for each header and the interval
between the start of a frame and the start of the following frame. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:LIN-SCHEDULING-TABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Communication::LinSchedulingTableEntry -->
	<xsd:group name="LIN-SCHEDULING-TABLE-ENTRY">
		<xsd:sequence>
			<xsd:element name="DELAY-TO-NEXT-FRAME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Relative delay of the frame in seconds to its successor in the schedule table.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::LinSchedulingTableEntry -->
	<xsd:complexType name="LIN-SCHEDULING-TABLE-ENTRY" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:LIN-SCHEDULING-TABLE-ENTRY"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::Frame -->
	<xsd:group name="FRAME">
		<xsd:annotation>
			<xsd:documentation>
			Data frame which is sent over a communication medium. Each Frame can be identified per channel by an Identifier (ID). 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="FRAME-ID" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The Identifier (ID) of the data frame on the channel. 
In FlexRay each frame is identified by its slot id and communication cycle (attributes of AbsoluetlyScheduledTiming).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="FRAME-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The frameLength specifies the length of the payload section in bytes.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="FRAME-TIMINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ABSOLUTELY-SCHEDULED-TIMING" type="AR:ABSOLUTELY-SCHEDULED-TIMING"/>
						<xsd:element name="CYCLIC-TIMING" type="AR:CYCLIC-TIMING"/>
						<xsd:element name="EVENT-CONTROLLED-TIMING" type="AR:EVENT-CONTROLLED-TIMING"/>
						<xsd:element name="RELATIVELY-SCHEDULED-TIMING" type="AR:RELATIVELY-SCHEDULED-TIMING"/>
						<xsd:element name="REQUEST-CONTROLLED-TIMING" type="AR:REQUEST-CONTROLLED-TIMING"/>
						<xsd:element name="TIMING" type="AR:TIMING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MINIMUM-DELAY-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			A minimum delay time between transmissions in seconds. If a transmission is requested before the minimumDelayTime expires, the next transmission is postponed until the delay time expires. The minimum delay time for the next transmission starts the moment the previous transmission is confirmed. (OSEK COM)  
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PDU-PROTOTYPES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PDU-PROTOTYPE" type="AR:PDU-PROTOTYPE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RECEIVER-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="RECEIVER-IREF" type="AR:FRAME--RECEIVER-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="TRANSMITTER-IREF" type="AR:FRAME--TRANSMITTER-IREF" minOccurs="0"/>
			<xsd:element name="USED-PHYSICAL-CHANNEL-IREF" type="AR:FRAME--USED-PHYSICAL-CHANNEL-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::Frame -->
	<xsd:complexType name="FRAME" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Data frame which is sent over a communication medium. Each Frame can be identified per channel by an Identifier (ID). 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:FRAME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="FRAME--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CAN-FRAME"/>
			<xsd:enumeration value="FLEXRAY-FRAME"/>
			<xsd:enumeration value="FRAME"/>
			<xsd:enumeration value="LIN-FRAME"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::Timing -->
	<xsd:group name="TIMING">
		<xsd:annotation>
			<xsd:documentation>
			A timing defines time behavior (e.g. Cyclic, Event Triggered) of a frame, PDU or a Signal. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="FREE-TEXT-CONDITIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="FREE-TEXT-CONDITION" type="AR:FREE-TEXT-CONDITION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::Timing -->
	<xsd:complexType name="TIMING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A timing defines time behavior (e.g. Cyclic, Event Triggered) of a frame, PDU or a Signal. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:TIMING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::FreeTextCondition -->
	<xsd:group name="FREE-TEXT-CONDITION">
		<xsd:annotation>
			<xsd:documentation>
			A Condition can be formulated as a free text. If a FreeTextCondition is aggregated in a Timing, then the timing is only valid if the condition holds. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONDITION" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Condition formulated as a free text.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::FreeTextCondition -->
	<xsd:complexType name="FREE-TEXT-CONDITION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A Condition can be formulated as a free text. If a FreeTextCondition is aggregated in a Timing, then the timing is only valid if the condition holds. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:FREE-TEXT-CONDITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::PDUPrototype -->
	<xsd:group name="PDU-PROTOTYPE">
		<xsd:annotation>
			<xsd:documentation>
			The PDU (Protocol Data Unit) is a collection of signals for transfer between nodes in a network. The PDU is sent within a frame over a communication medium. A PDU can contain multiplexed data. 


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="INCLUDED-CLUSTER-SIGNALS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLUSTER-SIGNAL" type="AR:CLUSTER-SIGNAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PDU-TYPE-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PDU-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="START-POSITION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This parameter is necessary to describe the position of a PDU within a frame.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="UPDATE-INDICATION-BIT-POSITION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Indication to the receivers that the corresponding PDU was updated by the
sender. The AUTOSAR FlexRay Interface explicitly defines a location for the update bit in the Frame that aggregates this PDUPrototype.

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::PDUPrototype -->
	<xsd:complexType name="PDU-PROTOTYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The PDU (Protocol Data Unit) is a collection of signals for transfer between nodes in a network. The PDU is sent within a frame over a communication medium. A PDU can contain multiplexed data. 


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PDU-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="PDU-PROTOTYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PDU-PROTOTYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::AbsolutelyScheduledTiming -->
	<xsd:group name="ABSOLUTELY-SCHEDULED-TIMING">
		<xsd:annotation>
			<xsd:documentation>
			Each frame in FlexRay is identified by its slot id and communication cycle. A description is provided by the usage of AbsolutelyScheduledTiming. 

In the static segment a frame can be sent multiple times within one communication cycle. For describing this case multiple AbsolutelyScheduledTimings have to be used. The main use case would be that a frame is sent twice within one communication cycle.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BASE-CYCLE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The first communication cycle where the frame is sent
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CYCLE-REPETITION" type="AR:ABSOLUTELY-SCHEDULED-TIMING-CYCLE-REPETITION-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of communication cycles (after the first cycle) whenever the frame is sent again. The FlexRay communication controller allows only determined values.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SLOT-ID" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			In the static part the SlotID defines the slot in which the frame is transmitted. 
The SlotID also determines, in combination with FlexrayCluster::numberOfStaticSlots, whether the frame is sent in static or dynamic segment. 
In the dynamic part, the slot id is equivalent to a priority. Lower dynamic slot ids are all sent until the end of the dynamic segment. Higher numbers, which were ignored that time, have to wait one cycle and then must try again.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::AbsolutelyScheduledTiming -->
	<xsd:complexType name="ABSOLUTELY-SCHEDULED-TIMING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Each frame in FlexRay is identified by its slot id and communication cycle. A description is provided by the usage of AbsolutelyScheduledTiming. 

In the static segment a frame can be sent multiple times within one communication cycle. For describing this case multiple AbsolutelyScheduledTimings have to be used. The main use case would be that a frame is sent twice within one communication cycle.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:TIMING"/>
			<xsd:group ref="AR:ABSOLUTELY-SCHEDULED-TIMING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="ABSOLUTELY-SCHEDULED-TIMING-CYCLE-REPETITION-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="1"/>
			<xsd:enumeration value="2"/>
			<xsd:enumeration value="4"/>
			<xsd:enumeration value="8"/>
			<xsd:enumeration value="16"/>
			<xsd:enumeration value="32"/>
			<xsd:enumeration value="64"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::ActiveCondition -->
	<xsd:group name="ACTIVE-CONDITION">
		<xsd:annotation>
			<xsd:documentation>
			Precondition that must be fulfilled by the system. If this precondition is not fulfilled the timing that aggregates this ActiveCondition is not active.
If a timing is not active, the frame is either not sent at all (if no other active timing exists), or the frame is sent since another timing is active and all conditions are met in that timing.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SYSTEM-STATES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SYSTEM-STATE-TRIGGER" type="AR:SYSTEM-STATE-TRIGGER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::ActiveCondition -->
	<xsd:complexType name="ACTIVE-CONDITION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Precondition that must be fulfilled by the system. If this precondition is not fulfilled the timing that aggregates this ActiveCondition is not active.
If a timing is not active, the frame is either not sent at all (if no other active timing exists), or the frame is sent since another timing is active and all conditions are met in that timing.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ACTIVE-CONDITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::SystemStateTrigger -->
	<xsd:group name="SYSTEM-STATE-TRIGGER">
		<xsd:annotation>
			<xsd:documentation>
			System state that must rule that the referring timing is activated. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SYSTEM-STATE-CONDITION" type="xsd:string" minOccurs="0" maxOccurs="unbounded">
				<xsd:annotation>
					<xsd:documentation>
			This attribute describes the system state. 

Examples for values are: CLAMP_15, CLAMP_30, CLAMP_87, CLAMP_RADIO, CHANNEL_ACTIVE. (These values are only examples, they are not standardized by AUTOSAR)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::SystemStateTrigger -->
	<xsd:complexType name="SYSTEM-STATE-TRIGGER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			System state that must rule that the referring timing is activated. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SYSTEM-STATE-TRIGGER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class Communication::CanFrame -->
	<xsd:complexType name="CAN-FRAME" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The frame description for the CAN Bus.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:FRAME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Communication::CyclicTiming -->
	<xsd:group name="CYCLIC-TIMING">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a cyclic sending behavior, e.g. used on CAN buses.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTIVE-CONDITION" type="AR:ACTIVE-CONDITION" minOccurs="0"/>
			<xsd:element name="CYCLE-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specification of the repeating cycle in seconds whenever the frame described by this timing is sent.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="START-CONDITION" type="AR:START-CONDITION" minOccurs="0"/>
			<xsd:element name="STARTING-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specification of the time in seconds that is needed before the frame can be sent the first time. This starting time is relative to the StartCondition.

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="STOP-CONDITION" type="AR:STOP-CONDITION" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::CyclicTiming -->
	<xsd:complexType name="CYCLIC-TIMING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a cyclic sending behavior, e.g. used on CAN buses.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:TIMING"/>
			<xsd:group ref="AR:CYCLIC-TIMING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::StartCondition -->
	<xsd:group name="START-CONDITION">
		<xsd:annotation>
			<xsd:documentation>
			Condition that must be fulfilled by the system or some signals that the cycle is started. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SIGNAL-STATES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SIGNAL-TRIGGER" type="AR:SIGNAL-TRIGGER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SYSTEM-STATES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SYSTEM-STATE-TRIGGER" type="AR:SYSTEM-STATE-TRIGGER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::StartCondition -->
	<xsd:complexType name="START-CONDITION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Condition that must be fulfilled by the system or some signals that the cycle is started. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:START-CONDITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::SignalTrigger -->
	<xsd:group name="SIGNAL-TRIGGER">
		<xsd:annotation>
			<xsd:documentation>
			The Signal Trigger describes the signal state that must rule that the referring timing is executed. The attribute dataEventCondition defines the primary condition when the condition is fulfilled. It is a Boolean Condition. If this Condition is TRUE, then the referring timing can be executed. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMPARED-SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CLUSTER-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-EVENT-CONDITION" type="AR:SIGNAL-TRIGGER-DATA-EVENT-CONDITION-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies what operation on the data mapped to this signal will trigger the sending of a frame.
onChange: send frame if data written changed compared to last value written
onUpdate: send frame whenever data is written
onNotDefault: send frame whenever value is different from default value
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::SignalTrigger -->
	<xsd:complexType name="SIGNAL-TRIGGER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The Signal Trigger describes the signal state that must rule that the referring timing is executed. The attribute dataEventCondition defines the primary condition when the condition is fulfilled. It is a Boolean Condition. If this Condition is TRUE, then the referring timing can be executed. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SIGNAL-TRIGGER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="SIGNAL-TRIGGER-DATA-EVENT-CONDITION-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ON-CHANGE"/>
			<xsd:enumeration value="ON-UPDATE"/>
			<xsd:enumeration value="ON-NOT-DEFAULT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::StopCondition -->
	<xsd:group name="STOP-CONDITION">
		<xsd:annotation>
			<xsd:documentation>
			Condition that must be fulfilled by the system or some signals that the cycle is stopped.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SIGNAL-STATES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SIGNAL-TRIGGER" type="AR:SIGNAL-TRIGGER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SYSTEM-STATES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SYSTEM-STATE-TRIGGER" type="AR:SYSTEM-STATE-TRIGGER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::StopCondition -->
	<xsd:complexType name="STOP-CONDITION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Condition that must be fulfilled by the system or some signals that the cycle is stopped.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:STOP-CONDITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::EventControlledTiming -->
	<xsd:group name="EVENT-CONTROLLED-TIMING">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a event driven sending behavior, e.g. used on CAN buses. The Frame is sent &quot;numberOfRepeats&quot; times separated by the repeatCycleTime. If numberOfRepeats = 1, then the frame is sent just once.  The debounce Time must elapses before the frame can be sent the next time.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTIVE-CONDITION" type="AR:ACTIVE-CONDITION" minOccurs="0"/>
			<xsd:element name="DEBOUNCE-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specification of the time in seconds that elapses before the frame can be sent the next time (Minimum repeat gap between two frames). This time is different to the minimumDelayTime, defined on the Frame Level. If a transmission is requested before the debounceTime expires, this request will be ignored. The next transmission will not be postponed.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NUMBER-OF-REPEATS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of times the frame is sent if the condition is met
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="REPEAT-CYCLE-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specification of the repeating cycle in seconds that is used to repeat the frame.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SEND-CONDITION" type="AR:SEND-CONDITION" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::EventControlledTiming -->
	<xsd:complexType name="EVENT-CONTROLLED-TIMING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a event driven sending behavior, e.g. used on CAN buses. The Frame is sent &quot;numberOfRepeats&quot; times separated by the repeatCycleTime. If numberOfRepeats = 1, then the frame is sent just once.  The debounce Time must elapses before the frame can be sent the next time.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:TIMING"/>
			<xsd:group ref="AR:EVENT-CONTROLLED-TIMING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::SendCondition -->
	<xsd:group name="SEND-CONDITION">
		<xsd:annotation>
			<xsd:documentation>
			Condition (Event) that must be fulfilled to cause the frame to be sent.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SIGNAL-STATES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SIGNAL-TRIGGER" type="AR:SIGNAL-TRIGGER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SYSTEM-STATES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SYSTEM-STATE-TRIGGER" type="AR:SYSTEM-STATE-TRIGGER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::SendCondition -->
	<xsd:complexType name="SEND-CONDITION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Condition (Event) that must be fulfilled to cause the frame to be sent.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SEND-CONDITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::EventTriggeredFrameSlot -->
	<xsd:group name="EVENT-TRIGGERED-FRAME-SLOT">
		<xsd:annotation>
			<xsd:documentation>
			Frame slot for an event triggered frame.
LIN Spec 2.0 defines: &quot;An event triggered frame is used as a placeholder to allow multiple slave nodes to provide its response. This is
useful when the signals involved are changed infrequently.&quot; 
The event triggered frame has an own frame id that is sent by the LIN master. The slaves may answer with one of the unconditional frames referenced.  
LIN Spec 2.0 defines: &quot;If more than one unconditional frame is associated with one event triggered frame (which is the normal case) they shall all be of equal length, use the same checksum model (i.e. mixing LIN 1.3 and LIN 2.0 frames is incorrect) and, furthermore, they shall all be published by different slave tasks.&quot; 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="EVENT-TRIGGERED-FRAME-ID" type="xsd:integer" minOccurs="0"/>
			<xsd:element name="UNCONDITIONAL-FRAME-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="UNCONDITIONAL-FRAME-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:LIN-FRAME--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::EventTriggeredFrameSlot -->
	<xsd:complexType name="EVENT-TRIGGERED-FRAME-SLOT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Frame slot for an event triggered frame.
LIN Spec 2.0 defines: &quot;An event triggered frame is used as a placeholder to allow multiple slave nodes to provide its response. This is
useful when the signals involved are changed infrequently.&quot; 
The event triggered frame has an own frame id that is sent by the LIN master. The slaves may answer with one of the unconditional frames referenced.  
LIN Spec 2.0 defines: &quot;If more than one unconditional frame is associated with one event triggered frame (which is the normal case) they shall all be of equal length, use the same checksum model (i.e. mixing LIN 1.3 and LIN 2.0 frames is incorrect) and, furthermore, they shall all be published by different slave tasks.&quot; 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:LIN-SCHEDULING-TABLE-ENTRY"/>
			<xsd:group ref="AR:EVENT-TRIGGERED-FRAME-SLOT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::LinFrame -->
	<xsd:group name="LIN-FRAME">
		<xsd:annotation>
			<xsd:documentation>
			The frame description for the LIN Bus.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="RESPONSE-ERROR-SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SIGNAL-POSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::LinFrame -->
	<xsd:complexType name="LIN-FRAME" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The frame description for the LIN Bus.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:FRAME"/>
			<xsd:group ref="AR:LIN-FRAME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="LIN-FRAME--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="LIN-FRAME"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Communication::FlexrayFrame -->
	<xsd:complexType name="FLEXRAY-FRAME" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Unlike with other communication systems - as for example CAN - the Frame ID is not sufficient for the identification. On FlexRay the communication cycle is used with SlotID for frame identification. These attributes are described by the AbsolutelyScheduledTiming class.


		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:FRAME"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Communication::GatewayEntry -->
	<xsd:group name="GATEWAY-ENTRY">
		<xsd:annotation>
			<xsd:documentation>
			A GatewayEntry describes the information routing by references to the source and the destination 
PDUPrototype or ClusterSignal.
There are two possible methods to route the data from one channel to another: SignalCopy and PDUCopy.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.namePlural="GATEWAY-ENTRIES"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="GATEWAY-ENTRY-ID" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Identify the gateway entry in the gateway table. May be used to define the ordering of the entries.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class Communication::GatewayType -->
	<xsd:group name="GATEWAY-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			A gateway is a functionality within an ECU that performs as a PDU or signal mapping function between two or more communication clusters. The same GatewayType may be reused in different systems. This is however only possible if the system topology and communication matrices that are referenced from the gateway are  reused as well.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="GATEWAY-ENTRIES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PDU-GATEWAY-ENTRY" type="AR:PDU-GATEWAY-ENTRY"/>
						<xsd:element name="SIGNAL-GATEWAY-ENTRY" type="AR:SIGNAL-GATEWAY-ENTRY"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="GATEWAY-LOCATION-IREF" type="AR:GATEWAY-TYPE--GATEWAY-LOCATION-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::GatewayType -->
	<xsd:complexType name="GATEWAY-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A gateway is a functionality within an ECU that performs as a PDU or signal mapping function between two or more communication clusters. The same GatewayType may be reused in different systems. This is however only possible if the system topology and communication matrices that are referenced from the gateway are  reused as well.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:GATEWAY-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="GATEWAY-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="GATEWAY-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::PDUGatewayEntry -->
	<xsd:group name="PDU-GATEWAY-ENTRY">
		<xsd:annotation>
			<xsd:documentation>
			PDUGatewayEntry describes the PDUCopy Method. In this case the PDU will be copied, i.e. the destination PDU will have the same content (signals) and structure (position and length of signals) as the PDU on the source channel. 
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.namePlural="PDU-GATEWAY-ENTRIES"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTION-ON-TIMEOUT" type="AR:PDU-GATEWAY-ENTRY-ACTION-ON-TIMEOUT-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			What to do if a timeout occurred:
- useDefaultValue: The default value of the signal will be transmitted. The default Value is the value that is sent in the PDU when no actual or no valid value is available for the COM-Layer that could be sent. This/These values are defined in the SWC-T: InvalidValue, InitValue
 
- useLastValue: The last sent value will be transmitted again. 
- dontSend: nothing will be transmitted
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DESTINATION-PDU" type="AR:PDU-GATEWAY-ENTRY-DESTINATION-PDU" minOccurs="0"/>
			<xsd:element name="SOURCE-PDU" type="AR:PDU-GATEWAY-ENTRY-SOURCE-PDU" minOccurs="0"/>
			<xsd:element name="TIME-OUT-CYCLE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Time in seconds. Is this value exceeded without that a value of the source is received, the action defined in actionOnTimeout is performed. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::PDUGatewayEntry -->
	<xsd:complexType name="PDU-GATEWAY-ENTRY" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			PDUGatewayEntry describes the PDUCopy Method. In this case the PDU will be copied, i.e. the destination PDU will have the same content (signals) and structure (position and length of signals) as the PDU on the source channel. 
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.namePlural="PDU-GATEWAY-ENTRIES"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:GATEWAY-ENTRY"/>
			<xsd:group ref="AR:PDU-GATEWAY-ENTRY"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="PDU-GATEWAY-ENTRY-ACTION-ON-TIMEOUT-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="USE-DEFAULT-VALUE"/>
			<xsd:enumeration value="USE-LAST-VALUE"/>
			<xsd:enumeration value="DONT-SEND"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::RelativelyScheduledTiming -->
	<xsd:group name="RELATIVELY-SCHEDULED-TIMING">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a sending behavior where the transmission order is predefined, e.g. used on LIN buses
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DELAY" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Relative delay of the frame in ms described by this timing to its predecessor in the schedule table.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="POSITION-IN-TABLE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Relative position of the frame described by this timing in the schedule table
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SCHEDULE-TABLE-NAME" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Identifier of the schedule table containing the frame described by the referring timing on the triggering channel.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::RelativelyScheduledTiming -->
	<xsd:complexType name="RELATIVELY-SCHEDULED-TIMING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a sending behavior where the transmission order is predefined, e.g. used on LIN buses
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:TIMING"/>
			<xsd:group ref="AR:RELATIVELY-SCHEDULED-TIMING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::RequestControlledTiming -->
	<xsd:group name="REQUEST-CONTROLLED-TIMING">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a request driven sending behavior, e.g. used on CAN buses. Semantics of this communication mechanism is that basic software stores values but does not send it out until a frame requesting the information is received.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTIVE-CONDITION" type="AR:ACTIVE-CONDITION" minOccurs="0"/>
			<xsd:element name="REQUESTING-FRAME-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:FRAME--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RESPONSE-TIME" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specification of the time in seconds that is needed before the frame can be sent after the requests arrival.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::RequestControlledTiming -->
	<xsd:complexType name="REQUEST-CONTROLLED-TIMING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specification of a request driven sending behavior, e.g. used on CAN buses. Semantics of this communication mechanism is that basic software stores values but does not send it out until a frame requesting the information is received.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:TIMING"/>
			<xsd:group ref="AR:REQUEST-CONTROLLED-TIMING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::SignalGatewayEntry -->
	<xsd:group name="SIGNAL-GATEWAY-ENTRY">
		<xsd:annotation>
			<xsd:documentation>
			SignalGatewayEntry describes the SignalCopy Method. In this case only one signal of the PDU will be copied to another PDU on the destination channel. The parameters on the destination channel like signal position will be defined through the PDU description of the destination PDU. I.e. the signal must be described in the source and the destination PDU.  For each signal which should be copied, one entry in this table has to be created. If you want e.g. to create one PDU on the destination channel from two Signals of the source channel, you have to make two entries in the table. 

The Signal Gateway Trigger Condition is described by the usage of the SendCondition on an EventControlledFrame and the referring signal state.  
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.namePlural="SIGNAL-GATEWAY-ENTRIES"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTION-ON-TIMEOUT" type="AR:SIGNAL-GATEWAY-ENTRY-ACTION-ON-TIMEOUT-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			What to do if a timeout occurred:
- useDefaultValue: The default value of the signal will be transmitted. 
The default Value is the value that is sent in the frame when no actual or no valid value is available for the COM-Layer that could be sent. This/These values are defined in the SWC-T:
InvalidValue;
InitValue
 
- useLastValue: The last sent value will be transmitted again. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DESTINATION-CLUSTER-SIGNAL" type="AR:SIGNAL-GATEWAY-ENTRY-DESTINATION-CLUSTER-SIGNAL" minOccurs="0"/>
			<xsd:element name="SOURCE-CLUSTER-SIGNAL" type="AR:SIGNAL-GATEWAY-ENTRY-SOURCE-CLUSTER-SIGNAL" minOccurs="0"/>
			<xsd:element name="TIME-OUT-CYCLE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Time in seconds. Is this value exceeded without that a value of the source is received, the action defined in actionOnTimeout is performed.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::SignalGatewayEntry -->
	<xsd:complexType name="SIGNAL-GATEWAY-ENTRY" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			SignalGatewayEntry describes the SignalCopy Method. In this case only one signal of the PDU will be copied to another PDU on the destination channel. The parameters on the destination channel like signal position will be defined through the PDU description of the destination PDU. I.e. the signal must be described in the source and the destination PDU.  For each signal which should be copied, one entry in this table has to be created. If you want e.g. to create one PDU on the destination channel from two Signals of the source channel, you have to make two entries in the table. 

The Signal Gateway Trigger Condition is described by the usage of the SendCondition on an EventControlledFrame and the referring signal state.  
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.namePlural="SIGNAL-GATEWAY-ENTRIES"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:GATEWAY-ENTRY"/>
			<xsd:group ref="AR:SIGNAL-GATEWAY-ENTRY"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="SIGNAL-GATEWAY-ENTRY-ACTION-ON-TIMEOUT-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="USE-DEFAULT-VALUE"/>
			<xsd:enumeration value="USE-LAST-VALUE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Communication::SporadicFrameSlot -->
	<xsd:group name="SPORADIC-FRAME-SLOT">
		<xsd:annotation>
			<xsd:documentation>
			By use of sporadic frames, the LIN master may send different unconditional frames in a specific scheduling table position, depending on events that occurred.  From LIN 2.0 specification: &quot;If multiple sporadic frames are associated with the same frame slot (the normal case), the most prioritized of the sporadic frames (which has an updated signal) shall be transferred in the frame slot. If none of the sporadic frames associated with a frame slot has an updated signal the frame slot shall be silent.&quot;
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SPORADIC-FRAME-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SPORADIC-FRAME-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:LIN-FRAME--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::SporadicFrameSlot -->
	<xsd:complexType name="SPORADIC-FRAME-SLOT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			By use of sporadic frames, the LIN master may send different unconditional frames in a specific scheduling table position, depending on events that occurred.  From LIN 2.0 specification: &quot;If multiple sporadic frames are associated with the same frame slot (the normal case), the most prioritized of the sporadic frames (which has an updated signal) shall be transferred in the frame slot. If none of the sporadic frames associated with a frame slot has an updated signal the frame slot shall be silent.&quot;
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:LIN-SCHEDULING-TABLE-ENTRY"/>
			<xsd:group ref="AR:SPORADIC-FRAME-SLOT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Communication::UnconditionalFrameSlot -->
	<xsd:group name="UNCONDITIONAL-FRAME-SLOT">
		<xsd:annotation>
			<xsd:documentation>
			Frame slot for an unconditional frame. An unconditional frame is a signal-carrying frame that is always sent in its allocated frame slot. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="UNCONDITIONAL-FRAME-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:LIN-FRAME--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Communication::UnconditionalFrameSlot -->
	<xsd:complexType name="UNCONDITIONAL-FRAME-SLOT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Frame slot for an unconditional frame. An unconditional frame is a signal-carrying frame that is always sent in its allocated frame slot. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:LIN-SCHEDULING-TABLE-ENTRY"/>
			<xsd:group ref="AR:UNCONDITIONAL-FRAME-SLOT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::CommunicationMatrixType_communicationCluster -->
	<xsd:group name="COMMUNICATION-MATRIX-TYPE-COMMUNICATION-CLUSTER">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMMUNICATION-CLUSTER-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMMUNICATION-CLUSTER--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::CommunicationMatrixType_communicationCluster -->
	<xsd:complexType name="COMMUNICATION-MATRIX-TYPE-COMMUNICATION-CLUSTER" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMMUNICATION-MATRIX-TYPE-COMMUNICATION-CLUSTER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::Frame_receiver -->
	<xsd:group name="FRAME--RECEIVER-IREF">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-COMMUNICATION-PORT-INSTANCE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-COMMUNICATION-PORT-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::Frame_receiver -->
	<xsd:complexType name="FRAME--RECEIVER-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:FRAME--RECEIVER-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::Frame_transmitter -->
	<xsd:group name="FRAME--TRANSMITTER-IREF">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-COMMUNICATION-PORT-INSTANCE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-COMMUNICATION-PORT-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::Frame_transmitter -->
	<xsd:complexType name="FRAME--TRANSMITTER-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:FRAME--TRANSMITTER-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::Frame_usedPhysicalChannel -->
	<xsd:group name="FRAME--USED-PHYSICAL-CHANNEL-IREF">
		<xsd:annotation>
			<xsd:documentation>
			


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			instanceRef.context="systemTopologyinstance"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PHYSICAL-CHANNEL-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PHYSICAL-CHANNEL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::Frame_usedPhysicalChannel -->
	<xsd:complexType name="FRAME--USED-PHYSICAL-CHANNEL-IREF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			


		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			instanceRef.context="systemTopologyinstance"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:FRAME--USED-PHYSICAL-CHANNEL-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::GatewayType_gatewayLocation -->
	<xsd:group name="GATEWAY-TYPE--GATEWAY-LOCATION-IREF">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="GATEWAY-LOCATION-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::GatewayType_gatewayLocation -->
	<xsd:complexType name="GATEWAY-TYPE--GATEWAY-LOCATION-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:GATEWAY-TYPE--GATEWAY-LOCATION-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::PDUGatewayEntry_destinationPDU -->
	<xsd:group name="PDU-GATEWAY-ENTRY-DESTINATION-PDU">
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-MATRIX-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMMUNICATION-MATRIX-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DESTINATION-PDU-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PDU-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::PDUGatewayEntry_destinationPDU -->
	<xsd:complexType name="PDU-GATEWAY-ENTRY-DESTINATION-PDU" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:PDU-GATEWAY-ENTRY-DESTINATION-PDU"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::PDUGatewayEntry_sourcePDU -->
	<xsd:group name="PDU-GATEWAY-ENTRY-SOURCE-PDU">
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-MATRIX-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMMUNICATION-MATRIX-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SOURCE-PDU-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PDU-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::PDUGatewayEntry_sourcePDU -->
	<xsd:complexType name="PDU-GATEWAY-ENTRY-SOURCE-PDU" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:PDU-GATEWAY-ENTRY-SOURCE-PDU"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SignalGatewayEntry_destinationClusterSignal -->
	<xsd:group name="SIGNAL-GATEWAY-ENTRY-DESTINATION-CLUSTER-SIGNAL">
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-MATRIX-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMMUNICATION-MATRIX-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DESTINATION-CLUSTER-SIGNAL-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CLUSTER-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SignalGatewayEntry_destinationClusterSignal -->
	<xsd:complexType name="SIGNAL-GATEWAY-ENTRY-DESTINATION-CLUSTER-SIGNAL" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SIGNAL-GATEWAY-ENTRY-DESTINATION-CLUSTER-SIGNAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SignalGatewayEntry_sourceClusterSignal -->
	<xsd:group name="SIGNAL-GATEWAY-ENTRY-SOURCE-CLUSTER-SIGNAL">
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-MATRIX-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMMUNICATION-MATRIX-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CLUSTER-SIGNAL-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CLUSTER-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SignalGatewayEntry_sourceClusterSignal -->
	<xsd:complexType name="SIGNAL-GATEWAY-ENTRY-SOURCE-CLUSTER-SIGNAL" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SIGNAL-GATEWAY-ENTRY-SOURCE-CLUSTER-SIGNAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class Topology::CANBus -->
	<xsd:group name="CAN-BUS">
		<xsd:annotation>
			<xsd:documentation>
			CAN specific attributes
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.namePlural="CAN-BUSES"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CAN-ADDRESSING-MODE" type="AR:CAN-BUS-CAN-ADDRESSING-MODE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The CAN bus supports 11-Bit (&quot;Standard&quot;) and 29-Bit (&quot;Extended&quot;) identifiers. This attributes constrains a CAN bus to the selected formats. On Extended-
Addressing it is also possible to have 11-Bit and 29-Bit CAN-identifiers. 
Predefined values are &quot;Standard&quot; and &quot;Extended&quot;.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::CANBus -->
	<xsd:complexType name="CAN-BUS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			CAN specific attributes
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.namePlural="CAN-BUSES"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMMUNICATION-CLUSTER"/>
			<xsd:group ref="AR:CAN-BUS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="CAN-BUS-CAN-ADDRESSING-MODE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="STANDARD"/>
			<xsd:enumeration value="EXTENDED"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Topology::CANCommunicationPortInstance -->
	<xsd:group name="CAN-COMMUNICATION-PORT-INSTANCE">
		<xsd:annotation>
			<xsd:documentation>
			CAN bus specific communication port attributes.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BRP" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			A clock prescaler value
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-PERMITTED-PROCESSING-PERIOD-JITTER" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies the maximum acceptable variance (normally delay) in seconds from the nominal Processing Period of the call to execute the Bus Communication SW. The cause of the jitter may be interrupts from tasks in the CPU with higher priority. This requirement must be taken into account when scheduling the software in the CPU. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PORT-TERMINATION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describes whether the transceiver communication port termination is on or off.
TRUE: communication port is terminated
FALSE: communication port is not terminated
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PROTOCOL-VERSION" type="AR:CAN-COMMUNICATION-PORT-INSTANCE-PROTOCOL-VERSION-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describes whether the CAN communication port is CAN &quot;2.0a&quot; or &quot;2.0b&quot; compliant.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="RECEIVE-PROCESSING-PERIOD" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies the nominal time interval between two consecutive calls to execute the Bus Communication SW (the COM layer) for receiving. Unit: seconds.
At the execution of the Bus Communication SW received frames are moved from receive buffers and their signal content made available to the application.

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SYNC-JUMP-WIDTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of quanta in the Synchronization Jump Width, SJW
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TIME-SEG-0" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of quanta before the sampling point
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TIME-SEG-1" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of quanta after the sampling point
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TRANSMIT-PROCESSING-PERIOD" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies the nominal time interval between two consecutive calls to execute the Bus Communication SW (the COM layer) for sending. Unit: seconds.
At the execution of the Bus Communication SW frames due for transmission are moved to the transmit buffers, and made available for arbitration on the bus (in the case of CAN).

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::CANCommunicationPortInstance -->
	<xsd:complexType name="CAN-COMMUNICATION-PORT-INSTANCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			CAN bus specific communication port attributes.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:ECU-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:group ref="AR:CAN-COMMUNICATION-PORT-INSTANCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Topology::ECUCommunicationPortInstance -->
	<xsd:group name="ECU-COMMUNICATION-PORT-INSTANCE">
		<xsd:annotation>
			<xsd:documentation>
			The ECU resource description describes the hardware properties of each ECU communication port. Some of these properties may be further restricted by more software related constraints. Therefore the communication port instance describes on one hand the real settings to that hardware and on the other hand some properties which are set by software only.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMM-PORT-ID" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The identifier for this communication port on the bus, which can be used as e.g. network management address. There must not be two identical communication port identifiers on the same communication cluster.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="COMMUNICATION-SPEED-PORT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Bus speed of this port in  bits per second
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PORT-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-COMMUNICATION-PORT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="WAKE-UP-ON-COMM-PORT-SUPPORTED" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			May the ECU be woken up on this communication port?
TRUE: wake up is possible
FALSE: wake up on bus is not supported
Note: This flag may only be set to TRUE if the feature is supported by both hardware and basic software.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::ECUCommunicationPortInstance -->
	<xsd:complexType name="ECU-COMMUNICATION-PORT-INSTANCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The ECU resource description describes the hardware properties of each ECU communication port. Some of these properties may be further restricted by more software related constraints. Therefore the communication port instance describes on one hand the real settings to that hardware and on the other hand some properties which are set by software only.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:ECU-COMMUNICATION-PORT-INSTANCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ECU-COMMUNICATION-PORT-INSTANCE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CAN-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:enumeration value="ECU-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:enumeration value="FLEXRAY-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:enumeration value="LIN-COMMUNICATION-PORT-INSTANCE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="CAN-COMMUNICATION-PORT-INSTANCE-PROTOCOL-VERSION-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="20-A"/>
			<xsd:enumeration value="20-B"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Topology::Connector -->
	<xsd:group name="CONNECTOR">
		<xsd:annotation>
			<xsd:documentation>
			The connector is used to describe the bus interfaces of the ECU. 

Each connector has a reference to exactly one communication port. The communication port can be referenced by several connector elements. This is important for the FlexRay Bus. 

FlexRay communicates via two physical channels. But only one controller in an ECU is responsible for both channels. Thus, two connectors (for channel A and for channel B) must reference to the same communication port. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMM-PORT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-COMMUNICATION-PORT-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::Connector -->
	<xsd:complexType name="CONNECTOR" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The connector is used to describe the bus interfaces of the ECU. 

Each connector has a reference to exactly one communication port. The communication port can be referenced by several connector elements. This is important for the FlexRay Bus. 

FlexRay communicates via two physical channels. But only one controller in an ECU is responsible for both channels. Thus, two connectors (for channel A and for channel B) must reference to the same communication port. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:CONNECTOR"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="CONNECTOR--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CONNECTOR"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Topology::ECUInstance -->
	<xsd:group name="ECU-INSTANCE">
		<xsd:annotation>
			<xsd:documentation>
			ECUInstances are used to define the ECUs used in the topology. The type of the ECU is defined by a reference to an ECU specified with the ECU resource description.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COM-PROCESSING-PERIOD" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The COM scheduling time is used in order to be able to calculate the worst case bus timing. The processing period shall be specified AUTOSAR conform in seconds.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="COMM-PORTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CAN-COMMUNICATION-PORT-INSTANCE" type="AR:CAN-COMMUNICATION-PORT-INSTANCE"/>
						<xsd:element name="ECU-COMMUNICATION-PORT-INSTANCE" type="AR:ECU-COMMUNICATION-PORT-INSTANCE"/>
						<xsd:element name="FLEXRAY-COMMUNICATION-PORT-INSTANCE" type="AR:FLEXRAY-COMMUNICATION-PORT-INSTANCE"/>
						<xsd:element name="LIN-COMMUNICATION-PORT-INSTANCE" type="AR:LIN-COMMUNICATION-PORT-INSTANCE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CONNECTORS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CONNECTOR" type="AR:CONNECTOR"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-ADDRESS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The unique address of the ECU within the car. Used e.g. for Onboard Diagnostic (OBD) addressing, general diagnostics, Network Management.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ECU-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="POWER-SUPPLY" type="AR:ECU-INSTANCE-POWER-SUPPLY-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Defines how the ECU is connected to  power feed.
Predefined values are 
Battery: the ECU is always connected to power
Ignition: the ECU has power feed if ignition is on
Accessory: the ECU has power feed if accessory is switched on.
Other: other power feed mode, such as selective power feed, e.g. under control of another ECU, etc.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PROCESSING-UNIT-ENDIANNESS" type="AR:BYTE-ORDER-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The Processing Unit endianness is the byte order in which the CPU interprets multi-byte integers from memory. The byte ordering &quot;Little Endian&quot; (MostSignificantByteLast) and &quot;Big Endian&quot; (MostSignificantByteFirst) can be selected. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SLEEP-MODE-SUPPORTED" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies whether the ECU instance may be put to a &quot;low power mode&quot;
TRUE: sleep mode is supported
FALSE: sleep mode is not supported
Note: This flag may only be set to TRUE if the feature is supported by both hardware and basic software.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP-ON-INTERNAL-SUPPORTED" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies whether the ECU may be woken from sleep mode on internal events, e.g. by timer or similar device built into the ECU.
TRUE: ECU may wake up on ECU internal event
FALSE: ECU does not support this feature
Note: This flag may only be set to TRUE if the feature is supported by both hardware and basic software.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP-ON-IO-SUPPORTED" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies whether the ECU may be woken up on IO ports (other than communication ports - those are specified separately).
TRUE: ECU may be woken up on IO ports (see ECU resource descriptions for details)
FALSE: not supported
Note: This flag may only be set to TRUE if the feature is supported by both hardware and basic software.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::ECUInstance -->
	<xsd:complexType name="ECU-INSTANCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			ECUInstances are used to define the ECUs used in the topology. The type of the ECU is defined by a reference to an ECU specified with the ECU resource description.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:TOPOLOGY-ELEMENT"/>
			<xsd:group ref="AR:ECU-INSTANCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="ECU-INSTANCE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ECU-INSTANCE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Topology::TopologyElement -->
	<xsd:group name="TOPOLOGY-ELEMENT">
		<xsd:annotation>
			<xsd:documentation>
			A Hub or an ECU. The optional parent-child references can be used for the description of tree topologies. Each element in the tree is appropriately indented to indicate its level in the hierarchy, and is connected to its parent and to the children.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CHILD-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CHILD-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:TOPOLOGY-ELEMENT--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PARENT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:TOPOLOGY-ELEMENT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="TOPOLOGY-ELEMENT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ECU-INSTANCE"/>
			<xsd:enumeration value="HUB"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="ECU-INSTANCE-POWER-SUPPLY-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="BATTERY"/>
			<xsd:enumeration value="IGNITION"/>
			<xsd:enumeration value="ACCESSORY"/>
			<xsd:enumeration value="OTHER"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Topology::FlexrayCluster -->
	<xsd:group name="FLEXRAY-CLUSTER">
		<xsd:annotation>
			<xsd:documentation>
			FlexRay specific attributes to the physical Medium
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACTION-POINT-OFFSET" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The offset of the action point in networks
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="BUS-GUARDIAN-ENABLE-PART" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Bus Guardian Inter Slot Gap (ISG) part that follows a guarded schedule element. Unit macroticks
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CAS-RX-LOW-MAX" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Upper limit of the Collision Avoidance Symbol (CAS) acceptance window. Unit:bitDuration
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CAS-RX-LOW-MIN" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Lower limit of the Collision Avoidance Symbol (CAS) acceptance window. Unit:bitDuration 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="COLD-START-ATTEMPTS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maximum number of times that a node in this cluster is permitted to attempt to start the cluster by initiating schedule synchronization
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CYCLE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Length of the cycle. Unit: seconds
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DYNAMIC-SLOT-IDLE-PHASE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The duration of the dynamic slot idle phase in minislots.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="LISTEN-NOISE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Upper limit for the start up and wake up listen timeout in the presence of noise. Expressed as a multiple of the cluster constant pdListenTimeout. Unit microticks
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MACRO-INITIAL-OFFSET" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			number of macroticks which describe the distance between the static slot boundary and the closed macrotick boundary of the secondary time reference point using the initial configured macrotick length
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MACRO-PER-CYCLE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of macroticks in a communication cycle
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MACROTICK-DURATION" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The duration of the cluster wide nominal macrotick. Unit: seconds
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-INITIALISATION-ERROR" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maximum error that a node may have after initialization. Unit: seconds
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-WITHOUT-CLOCK-CORRECTION-FATAL" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Threshold concerning vClockCorrectionFailedCounter. Defines when the Communication Controller (CC) shall change from normal or passive state to hold state. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-WITHOUT-CLOCK-CORRECTION-PASSIVE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Threshold concerning vClockCorrectionFailedCounter. Defines when the Communication Controller (CC) shall change from normal or passive state to hold state. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MINISLOT-ACTION-POINT-OFFSET" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The Offset of the action point within a minislot. Unit: macroticks
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MINISLOT-DURATION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The duration of a minislot (dynamic segment). Unit: macroticks.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NETWORK-IDLE-TIME" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The duration of the network idle time in macroticks
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NETWORK-MANAGEMENT-VECTOR-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Length of the Network Management vector on a cluster. Unit: Bytes
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NUMBER-OF-MINISLOTS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			number of Minislots in the dynamic segment.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NUMBER-OF-STATIC-SLOTS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of static slots in the static segment.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OFFSET-CORRECTION-START" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Start of the offset correction phase within the Network Idle Time (NIT), expressed as the number of macroticks from the start of cycle. Unit: macroticks 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PAYLOAD-LENGTH-STATIC" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Globally configured payload length of a static frame. Unit: 16-bit WORDS.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SAMPLE-CLOCK-PERIOD" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Sample clock period. Unit: seconds
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="STATIC-SLOT-DURATION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The duration of a slot in the static segment. Unit: macroticks
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SYMBOL-WINDOW" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The duration of the symbol window. Unit: macroticks
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SYNC-NODE-MAX" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The maximum number of sync nodes allowed in the cluster
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TRANSMISSION-START-SEQUENCE-DURATION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Duration of the Transmission Start Sequence. Unit: bit
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP-SYMBOL-RX-IDLE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of bits used by the node to test the duration of the idle portion of a received wake up symbol.  Unit:bitDuration
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP-SYMBOL-RX-LOW" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of bits used by the node to test the LOW portion of a received wake up symbol. 
Unit:bitDuration 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP-SYMBOL-RX-WINDOW" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of bits used by a node to test the overall duration of a received wake up symbol. Unit: gdBit
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP-SYMBOL-TX-IDLE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of bits used by the node to transmit the idle part of a wake up symbol. Unit: gDbit
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP-SYMBOL-TX-LOW" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of bits used by the node to transmit the LOW part of a wake up symbol. Unit:bitDuration 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::FlexrayCluster -->
	<xsd:complexType name="FLEXRAY-CLUSTER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			FlexRay specific attributes to the physical Medium
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMMUNICATION-CLUSTER"/>
			<xsd:group ref="AR:FLEXRAY-CLUSTER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Topology::FlexrayCommunicationPortInstance -->
	<xsd:group name="FLEXRAY-COMMUNICATION-PORT-INSTANCE">
		<xsd:annotation>
			<xsd:documentation>
			FlexRay bus specific communication port attributes.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ACCEPTED-STARTUP-RANGE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Expanded range of measured clock deviation allowed for startup frames during integration. Unit:microtick
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ALLOW-HALT-DUE-TO-CLOCK" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Boolean flag that controls the transition to the POC:halt state due to a clock synchronization errors. 
If set to true, the Communication Controller is allowed to transition to POC:halt. 
If set to false, the Communication Controller will not transition to the POC:halt state but will enter or remain in the normal POC (passive State).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ALLOW-PASSIVE-TO-ACTIVE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of consecutive even/odd cycle pairs that must have valid clock correction terms before the Communication Controller will be allowed to transition from the POC:normal passive state to POC:normal active state. If set to 0, the Communication Controller is not allowed to transition from POC:norm
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CLUSTER-DRIFT-DAMPING" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The cluster drift damping factor used in clock synchronization rate correction in microticks
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DELAY-COMPENSATION-A" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Value used to compensate for reception delays on channel A
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DELAY-COMPENSATION-B" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Value used to compensate for reception delays on channel B
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DYNAMIC-SEGMENT-ENABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Boolean flag that configures the Bus Guardian Schedule
Monitoring Service to expect transmissions within
the dynamic segment.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="EXTERN-OFFSET-CORRECTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Fixed amount added or subtracted to the calculated offset correction term to facilitate external offset correction, expressed in node-local microticks.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="EXTERN-RATE-CORRECTION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Fixed amount added or subtracted to the calculated rate correction term to facilitate external rate correction, expressed in node-local microticks.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="KEY-SLOT-ID" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			ID of the slot used to transmit the startup frame, sync frame, or designated single slot frame.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="KEY-SLOT-USED-FOR-START-UP" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Flag indicating whether the Key Slot is used to transmit a startup frame. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="KEY-SLOT-USED-FOR-SYNC" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Flag indicating whether the Key Slot is used to transmit a sync frame. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="LATEST-TX" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of the last minislot in which a transmission can start in the dynamic segment for the respective node
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="LISTEN-TIMEOUT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Upper limit for the start up listen timeout and wake up listen timeout. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-DRIFT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum drift offset in microticks between two nodes that operate with unsynchronized clocks over one communication cycle.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAXIMUM-DYNAMIC-PAYLOAD-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum payload length for the dynamic channel of a frame in 16 bit WORDS.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MICRO-INITIAL-OFFSET-A" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of microticks between the closest macrotick boundary described by gMacroInitialOffset and the secondary time reference point.  The parameter depends on pDelayCompensationA and therefore it has to be set independently for each channel.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MICRO-INITIAL-OFFSET-B" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of microticks between the closest macrotick boundary described by gMacroInitialOffset and the secondary time reference point.  The parameter depends on pDelayCompensationB and therefore it has to be set independently for each channel. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MICRO-PER-CYCLE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The nominal number of microticks in a communication cycle
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MICRO-PER-MACRO-NOM" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of microticks per nominal macrotick that all implementations must support.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MICROTICK-DURATION" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Duration of a microtick. This attribute can be derived from samplePerMicrotick and gdSampleClockPeriod. 
Unit: seconds
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SAMPLES-PER-MICROTICK" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of samples per microtick
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SINGLE-SLOT-ENABLED" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Flag indicating whether or not the node shall enter single slot mode following startup. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="START-UP-NODE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Indicates that the node is a startup node (startup frame configured; connected to gChannels)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SYNC-SLOT" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The number of the static slot in which a sync frame shall be sent, if a sync frame shall be sent
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="WAKE-UP-PATTERN" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Number of repetitions of the Tx-wakeup symbol to be sent during the CC_WakeupSend state of this Node in the cluster
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::FlexrayCommunicationPortInstance -->
	<xsd:complexType name="FLEXRAY-COMMUNICATION-PORT-INSTANCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			FlexRay bus specific communication port attributes.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:ECU-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:group ref="AR:FLEXRAY-COMMUNICATION-PORT-INSTANCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Topology::Hub -->
	<xsd:group name="HUB">
		<xsd:annotation>
			<xsd:documentation>
			A hub connects several PhysicalMediumSegments together. Hubs are only used to describe the detailed bus topology of star and more complex topologies. They are not used on basic bus topologies.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="HUB-TYPE" type="AR:HUB-HUB-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The type of hub. Predefined values are &quot;ActiveHub&quot;, &quot;PassiveHub&quot;
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::Hub -->
	<xsd:complexType name="HUB" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A hub connects several PhysicalMediumSegments together. Hubs are only used to describe the detailed bus topology of star and more complex topologies. They are not used on basic bus topologies.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:TOPOLOGY-ELEMENT"/>
			<xsd:group ref="AR:HUB"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="HUB--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="HUB"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="HUB-HUB-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="ACTIVE-HUB"/>
			<xsd:enumeration value="PASSIVE-HUB"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Topology::LINCommunicationPortInstance -->
	<xsd:group name="LIN-COMMUNICATION-PORT-INSTANCE">
		<xsd:annotation>
			<xsd:documentation>
			LIN bus specific communication port instance attributes.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DIAGNOSTIC-ADDRESS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Diagnostic address of the LIN node. This attribute is only use for LIN 1.2 and LIN 1.3 slaves.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="FUNCTION-ID" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			function_id is a 16 bit number assigned to the product by the supplier to make it unique.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="INITIAL-NAD" type="xsd:integer" minOccurs="0" maxOccurs="2">
				<xsd:annotation>
					<xsd:documentation>
			Unique ID used e.g. for automatic configuration of LIN networks. The Node Address for Diagnostic (NAD) is not part of the LIN 1.2 and 1.3 specification. The NAD is only assigned to LIN slaves. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-MESSAGE-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The max_message_length property applies to the diagnostic transport layer only; it defines the maximum length of a diagnostic message in bits.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX-PERMITTED-SLAVE-JITTER" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum jitter time of responding frames, only needed for LIN slaves. Unit is seconds.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="NODE-ROLE" type="AR:LIN-COMMUNICATION-PORT-INSTANCE-NODE-ROLE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies whether the LIN node is master or slave on the bus it is connected to with this communication port
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="P-2-MIN" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			P2_min specifies the minimum time in seconds between a master request frame and the following slave response frame for the node to be able to prepare the response.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PROTOCOL-VERSION" type="AR:LIN-COMMUNICATION-PORT-INSTANCE-PROTOCOL-VERSION-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The version of the protocol used. Predefined values for LIN are &quot;1.2&quot;, &quot;1.3&quot;, &quot;2.0&quot;.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ST-MIN" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			ST_min specifies the minimum time in seconds between two slave response frames in a multi-PDU response, i.e. it only applies to the diagnostic transport layer.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SUPPLIER-ID" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Unique supplier ID of the LIN slave. A unique ID is assigned to every member of the LIN consortium. It may be used for the automatic configuration of LIN 2.0 slave nodes.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SUPPORT-SID" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Lists all Service Identifier (SID) values that are supported by the node. Example: {0xb0, 0xb1, 0xb2}
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TIME-BASE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Time base is mandatory for the master. It is not used for slaves. 
LIN 2.0 Spec states: &quot;The time_base value specifies the used time base in the master node to generate the maximum allowed frame transfer time.&quot; 
The time base shall be specified AUTOSAR conform in seconds.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="TIME-BASE-JITTER" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			timeBaseJitter is a mandatory attribute for the master and not used for slaves. 
LIN 2.0 Spec states: &quot;The jitter value specifies the differences between the maximum and minimum delay from time base start point to the frame header sending start point (falling edge of BREAK signal).&quot; 
The jitter shall be specified AUTOSAR conform in seconds.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="VARIANT-ID" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The Variant ID is used for the product identification and is an 8 bit value specifying the variant. The variant ID shall be changed whenever the product is changed but with unaltered function.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::LINCommunicationPortInstance -->
	<xsd:complexType name="LIN-COMMUNICATION-PORT-INSTANCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			LIN bus specific communication port instance attributes.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:ECU-COMMUNICATION-PORT-INSTANCE"/>
			<xsd:group ref="AR:LIN-COMMUNICATION-PORT-INSTANCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="LIN-COMMUNICATION-PORT-INSTANCE-PROTOCOL-VERSION-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="12"/>
			<xsd:enumeration value="13"/>
			<xsd:enumeration value="20"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="LIN-COMMUNICATION-PORT-INSTANCE-NODE-ROLE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MASTER"/>
			<xsd:enumeration value="SLAVE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Topology::LINSubBus -->
	<xsd:group name="LIN-SUB-BUS">
		<xsd:annotation>
			<xsd:documentation>
			LIN sub-bus definition
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MAX-PERMITTED-SLAVE-JITTER" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Maximum jitter time of responding frames, only needed for LIN slaves. Unit is seconds.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::LINSubBus -->
	<xsd:complexType name="LIN-SUB-BUS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			LIN sub-bus definition
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMMUNICATION-CLUSTER"/>
			<xsd:group ref="AR:LIN-SUB-BUS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Topology::PhysicalChannel -->
	<xsd:group name="PHYSICAL-CHANNEL">
		<xsd:annotation>
			<xsd:documentation>
			A physical channel is the transmission medium that is used to send and receive information between two communicating ECUs. Each CommunicationCluster has at least one physical channel. Bus systems like CAN and LIN only have exactly one PhysicalChannel. A FlexRay cluster may have more than one PhysicalChannels that may be used in parallel for redundant communication.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PHYSICAL-SEGMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PHYSICAL-MEDIUM-SEGMENT" type="AR:PHYSICAL-MEDIUM-SEGMENT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::PhysicalChannel -->
	<xsd:complexType name="PHYSICAL-CHANNEL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A physical channel is the transmission medium that is used to send and receive information between two communicating ECUs. Each CommunicationCluster has at least one physical channel. Bus systems like CAN and LIN only have exactly one PhysicalChannel. A FlexRay cluster may have more than one PhysicalChannels that may be used in parallel for redundant communication.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PHYSICAL-CHANNEL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="PHYSICAL-CHANNEL--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PHYSICAL-CHANNEL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Topology::PhysicalMediumSegment -->
	<xsd:group name="PHYSICAL-MEDIUM-SEGMENT">
		<xsd:annotation>
			<xsd:documentation>
			A PhysicalMediumSegment defines a set of communicating ECUs, which has the property of providing the identical physical data representation (e.g. electrical potential) to the all connected hardware (ECUs or Hubs). A PhysicalChannel may be implemented by several segments, which are then connected via (active or passive) Hubs. A PhysicalMediumSegment may connect individual ECUs together (for bus topologies), or connects hub and ECU(s) etc. Each PhysicalChannel consists of at least one segment; CAN and LIN have normally only a single segment, FlexRay can consist of more than one segments. These segments are then connected with each other via one or more Hubs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONNECTED-ECU-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CONNECTED-ECU-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:CONNECTOR--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CONNECTED-HUB-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CONNECTED-HUB-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:HUB--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PHYSICAL-MEDIUM-DATA-LINES" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Describes the number of physical wires/media used for data transmission. (E.g. single wire CAN has this value set to 1, LIN also 1)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PHYSICAL-MEDIUM-TYPE" type="AR:PHYSICAL-MEDIUM-SEGMENT-PHYSICAL-MEDIUM-TYPE-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Type of the physical medium on this segment.


		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::PhysicalMediumSegment -->
	<xsd:complexType name="PHYSICAL-MEDIUM-SEGMENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A PhysicalMediumSegment defines a set of communicating ECUs, which has the property of providing the identical physical data representation (e.g. electrical potential) to the all connected hardware (ECUs or Hubs). A PhysicalChannel may be implemented by several segments, which are then connected via (active or passive) Hubs. A PhysicalMediumSegment may connect individual ECUs together (for bus topologies), or connects hub and ECU(s) etc. Each PhysicalChannel consists of at least one segment; CAN and LIN have normally only a single segment, FlexRay can consist of more than one segments. These segments are then connected with each other via one or more Hubs.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PHYSICAL-MEDIUM-SEGMENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="PHYSICAL-MEDIUM-SEGMENT-PHYSICAL-MEDIUM-TYPE-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="OPTICAL"/>
			<xsd:enumeration value="TWISTED-PAIR"/>
			<xsd:enumeration value="SHIELDED-TWISTED-PAIR"/>
			<xsd:enumeration value="SINGLEWIRE"/>
			<xsd:enumeration value="WIRELESS"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class Topology::SystemTopologyType -->
	<xsd:group name="SYSTEM-TOPOLOGY-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			The system topology, which may be reused in different systems.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-CLUSTERS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CAN-BUS" type="AR:CAN-BUS"/>
						<xsd:element name="FLEXRAY-CLUSTER" type="AR:FLEXRAY-CLUSTER"/>
						<xsd:element name="LIN-SUB-BUS" type="AR:LIN-SUB-BUS"/>
						<xsd:element name="UNSPECIFIED-CONNECTION" type="AR:UNSPECIFIED-CONNECTION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="TOPOLOGY-ELEMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ECU-INSTANCE" type="AR:ECU-INSTANCE"/>
						<xsd:element name="HUB" type="AR:HUB"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class Topology::SystemTopologyType -->
	<xsd:complexType name="SYSTEM-TOPOLOGY-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The system topology, which may be reused in different systems.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SYSTEM-TOPOLOGY-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SYSTEM-TOPOLOGY-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SYSTEM-TOPOLOGY-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class Topology::UnspecifiedConnection -->
	<xsd:complexType name="UNSPECIFIED-CONNECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			UnspecifiedConnection may be used for proprietary bus systems, direct connections between I/O-ports of ECUs etc.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMMUNICATION-CLUSTER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class Topology::CommunicationCluster -->
	<xsd:group name="COMMUNICATION-CLUSTER">
		<xsd:annotation>
			<xsd:documentation>
			The CommunicationCluster is the main element to describe the topological connection of communicating ECUs. All ECUs within a CommunicationCluster communicate within the same address range. A CommunicationCluster aggregates one or more physical channels. All physical channels that are aggregated by a communication cluster  are synchronized with each other.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-SPEED-BUS" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Bus speed in bits per second
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PHYSICAL-CHANNELS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PHYSICAL-CHANNEL" type="AR:PHYSICAL-CHANNEL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROTOCOL-NAME" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The name of the protocol used. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PROTOCOL-VERSION" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The version of the protocol used.

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="COMMUNICATION-CLUSTER--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CAN-BUS"/>
			<xsd:enumeration value="FLEXRAY-CLUSTER"/>
			<xsd:enumeration value="LIN-SUB-BUS"/>
			<xsd:enumeration value="UNSPECIFIED-CONNECTION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SystemSignal::ClusterSignalReceiver -->
	<xsd:group name="CLUSTER-SIGNAL-RECEIVER">
		<xsd:annotation>
			<xsd:documentation>
			A receiver of the cluster signal. Since different receivers can have different communication attribute values, a separate class is used per receiver.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-PORT-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMMUNICATION-PORT-IREF" type="AR:CLUSTER-SIGNAL-RECEIVER--COMMUNICATION-PORT-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="TIMEOUT" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Timeout in seconds. If the timeout occurs without  receiving the signal, the ECU shall take appropriate actions.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemSignal::ClusterSignalReceiver -->
	<xsd:complexType name="CLUSTER-SIGNAL-RECEIVER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A receiver of the cluster signal. Since different receivers can have different communication attribute values, a separate class is used per receiver.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLUSTER-SIGNAL-RECEIVER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SystemSignal::ClusterSignalTransmitter -->
	<xsd:group name="CLUSTER-SIGNAL-TRANSMITTER">
		<xsd:annotation>
			<xsd:documentation>
			A transmitter of the cluster signal. Since different transmitters can have different communication attribute values, a separate class is used per transmitter.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-PORT-IREF" type="AR:CLUSTER-SIGNAL-TRANSMITTER--COMMUNICATION-PORT-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemSignal::ClusterSignalTransmitter -->
	<xsd:complexType name="CLUSTER-SIGNAL-TRANSMITTER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A transmitter of the cluster signal. Since different transmitters can have different communication attribute values, a separate class is used per transmitter.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLUSTER-SIGNAL-TRANSMITTER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SystemSignal::SystemSignal -->
	<xsd:group name="SYSTEM-SIGNAL">
		<xsd:annotation>
			<xsd:documentation>
			The system signal represents the communication system&apos;s view of data exchanged between SW components which reside on different ECUs. The system signals allow to represent this communication in a flattened structure, with (at least) one system signal defined for each data element sent or received by a SW component instance. If data has to be sent over gateways, there is still only one system signal representing this data. The representation of the data on the individual communication systems is done by the cluster signals.
 
System signals can be defined independently of frames and PDUs. This allows a development methodology where the signals are defined first, and are assigned to frames in a later stage. 

According to the COM Specification, signal groups without signals are allowed. These have a &quot;signalLength&quot; = 0. In this case there shall be an &quot;update-bit&quot; configured. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="NEEDS-UPDATE-INDICATION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Boolean value that defines whether a UpdateIndicationBit has to be defined in the PDU that is associated with this SystemSignal. If this attribute is omitted, no UpdateIndication bit will be added to the PDU.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SIGNAL-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The signalLength specifies the size of the signal in bits. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SIGNAL-TIMING-REQUIREMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ABSOLUTELY-SCHEDULED-TIMING" type="AR:ABSOLUTELY-SCHEDULED-TIMING"/>
						<xsd:element name="CYCLIC-TIMING" type="AR:CYCLIC-TIMING"/>
						<xsd:element name="EVENT-CONTROLLED-TIMING" type="AR:EVENT-CONTROLLED-TIMING"/>
						<xsd:element name="RELATIVELY-SCHEDULED-TIMING" type="AR:RELATIVELY-SCHEDULED-TIMING"/>
						<xsd:element name="REQUEST-CONTROLLED-TIMING" type="AR:REQUEST-CONTROLLED-TIMING"/>
						<xsd:element name="TIMING" type="AR:TIMING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemSignal::SystemSignal -->
	<xsd:complexType name="SYSTEM-SIGNAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The system signal represents the communication system&apos;s view of data exchanged between SW components which reside on different ECUs. The system signals allow to represent this communication in a flattened structure, with (at least) one system signal defined for each data element sent or received by a SW component instance. If data has to be sent over gateways, there is still only one system signal representing this data. The representation of the data on the individual communication systems is done by the cluster signals.
 
System signals can be defined independently of frames and PDUs. This allows a development methodology where the signals are defined first, and are assigned to frames in a later stage. 

According to the COM Specification, signal groups without signals are allowed. These have a &quot;signalLength&quot; = 0. In this case there shall be an &quot;update-bit&quot; configured. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SYSTEM-SIGNAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SYSTEM-SIGNAL--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SYSTEM-SIGNAL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SystemSignal::SystemSignalGroup -->
	<xsd:group name="SYSTEM-SIGNAL-GROUP">
		<xsd:annotation>
			<xsd:documentation>
			A signal group refers to a set of signals that must always be kept together. A signal group is used to guarantee the atomic transfer of AUTOSAR composite data types.

  
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONTAINED-SIGNALS-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CONTAINED-SIGNALS-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemSignal::SystemSignalGroup -->
	<xsd:complexType name="SYSTEM-SIGNAL-GROUP" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A signal group refers to a set of signals that must always be kept together. A signal group is used to guarantee the atomic transfer of AUTOSAR composite data types.

  
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SYSTEM-SIGNAL-GROUP"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SYSTEM-SIGNAL-GROUP--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SYSTEM-SIGNAL-GROUP"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SystemSignal::ClusterSignal -->
	<xsd:group name="CLUSTER-SIGNAL">
		<xsd:annotation>
			<xsd:documentation>
			A cluster signal represents the system signal on one specific communication cluster. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="RECEIVERS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLUSTER-SIGNAL-RECEIVER" type="AR:CLUSTER-SIGNAL-RECEIVER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIGNAL-POSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SIGNAL-POSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="TRANSMITTER" type="AR:CLUSTER-SIGNAL-TRANSMITTER" minOccurs="0"/>
			<xsd:element name="UPDATE-INDICATION-BIT-POSITION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The UpdateIndicationBit indicates to the receivers that the clusterSignal was updated by the sender. Length is always one bit. The UpdateIndicationBitPosition attribute describes the position of the update bit within the PDU. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SystemSignal::ClusterSignal -->
	<xsd:complexType name="CLUSTER-SIGNAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A cluster signal represents the system signal on one specific communication cluster. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:CLUSTER-SIGNAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="CLUSTER-SIGNAL--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CLUSTER-SIGNAL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class _instanceRef::ClusterSignalReceiver_communicationPort -->
	<xsd:group name="CLUSTER-SIGNAL-RECEIVER--COMMUNICATION-PORT-IREF">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-COMMUNICATION-PORT-INSTANCE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-COMMUNICATION-PORT-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ClusterSignalReceiver_communicationPort -->
	<xsd:complexType name="CLUSTER-SIGNAL-RECEIVER--COMMUNICATION-PORT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:CLUSTER-SIGNAL-RECEIVER--COMMUNICATION-PORT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ClusterSignalTransmitter_communicationPort -->
	<xsd:group name="CLUSTER-SIGNAL-TRANSMITTER--COMMUNICATION-PORT-IREF">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-COMMUNICATION-PORT-INSTANCE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-COMMUNICATION-PORT-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ClusterSignalTransmitter_communicationPort -->
	<xsd:complexType name="CLUSTER-SIGNAL-TRANSMITTER--COMMUNICATION-PORT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:CLUSTER-SIGNAL-TRANSMITTER--COMMUNICATION-PORT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class PDUStructure::Multiplexer -->
	<xsd:group name="MULTIPLEXER">
		<xsd:annotation>
			<xsd:documentation>
			A multiplexer is used to define variable parts within a PDU that may carry different signals. 
The receivers of such a PDU can determine which signals are transmitted by evaluating the selector field, which carries a unique selector code for each sub-part.  
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATAS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SUB-PDU" type="AR:SUB-PDU"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SELECTOR-FIELD-BYTE-ORDER" type="AR:BYTE-ORDER-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This parameter defines the byte order of the selector field. 
 The byte ordering &quot;Little Endian&quot; (MostSignificantByteLast) and &quot;Big Endian&quot; (MostSignificantByteFirst) can be selected. 
The value of this attribute impacts the absolute position of the selector field into the PDU.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SELECTOR-FIELD-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The size in bits of the selector field shall be configurable in a range of one bit and eight bits. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SELECTOR-FIELD-START-POSITION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This parameter is necessary to describe the position of the selector field within the PDU.
 
It denotes the least significant bit for &quot;Little Endian&quot; and the most significant bit for &quot;Big Endian&quot; (see the description of the selectorFieldByteOrder attribute).
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PDUStructure::Multiplexer -->
	<xsd:complexType name="MULTIPLEXER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A multiplexer is used to define variable parts within a PDU that may carry different signals. 
The receivers of such a PDU can determine which signals are transmitted by evaluating the selector field, which carries a unique selector code for each sub-part.  
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:MULTIPLEXER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class PDUStructure::SubPDU -->
	<xsd:group name="SUB-PDU">
		<xsd:annotation>
			<xsd:documentation>
			A multiplexed PDU consists of a static part and a dynamic part, where the static part consists of zero or more signals and  the dynamic part consists of the selector field and one or more signals. Each part of a multiplexed PDU, the static part and the different dynamic parts, are described as a SubPDU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DYNAMIC-SUB-PDU-TIMINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ABSOLUTELY-SCHEDULED-TIMING" type="AR:ABSOLUTELY-SCHEDULED-TIMING"/>
						<xsd:element name="CYCLIC-TIMING" type="AR:CYCLIC-TIMING"/>
						<xsd:element name="EVENT-CONTROLLED-TIMING" type="AR:EVENT-CONTROLLED-TIMING"/>
						<xsd:element name="RELATIVELY-SCHEDULED-TIMING" type="AR:RELATIVELY-SCHEDULED-TIMING"/>
						<xsd:element name="REQUEST-CONTROLLED-TIMING" type="AR:REQUEST-CONTROLLED-TIMING"/>
						<xsd:element name="TIMING" type="AR:TIMING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="INCLUDED-SIGNALS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SIGNAL-POSITION" type="AR:SIGNAL-POSITION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SELECTOR-FIELD-CODE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The selector field is part of a multiplexed PDU. It consists of contiguous bits. The value of the selector field selects the layout of the multiplexed part of the PDU. This attribute is only valid for the dynamic part of the PDU.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="START-POSITION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The position of the static and the dynamic part of the multiplexer in the PDU. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SUB-PDU-SIZE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The size of the SubPDU in bits. The size is limited by the PDUSize.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PDUStructure::SubPDU -->
	<xsd:complexType name="SUB-PDU" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			A multiplexed PDU consists of a static part and a dynamic part, where the static part consists of zero or more signals and  the dynamic part consists of the selector field and one or more signals. Each part of a multiplexed PDU, the static part and the different dynamic parts, are described as a SubPDU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SUB-PDU"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class PDUStructure::PDUType -->
	<xsd:group name="PDU-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			PDUType defines the structure of a PDU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="INCLUDED-SIGNALS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SIGNAL-POSITION" type="AR:SIGNAL-POSITION"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MULTIPLEXER-DYNAMIC-PART" type="AR:MULTIPLEXER" minOccurs="0"/>
			<xsd:element name="MULTIPLEXER-STATIC-PART" type="AR:SUB-PDU" minOccurs="0"/>
			<xsd:element name="NEEDS-UPDATE-INDICATION" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Boolean value that defines whether a UpdateIndicationBit has to be defined in the Frame that is associated with this PDUType. If this attribute is omitted, no UpdateIndication bit will be added to the Frame. 
The AUTOSAR FlexRay Interface explicitly defines a location for the update
bit that relates to a PDU.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PDU-LENGTH" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The size of the PDU in bits. The size is limited by the frameLength.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PDUStructure::PDUType -->
	<xsd:complexType name="PDU-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			PDUType defines the structure of a PDU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PDU-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="PDU-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PDU-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class PDUStructure::SignalPosition -->
	<xsd:group name="SIGNAL-POSITION">
		<xsd:annotation>
			<xsd:documentation>
			The signal position defines which system signal is transmitted at which position within the aggregating PDU. The SignalPosition must be defined within a PDU or a SubPDU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PACKING-BYTE-ORDER" type="AR:BYTE-ORDER-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This parameter defines the order of the bytes of the signal are packed into the PDU. The byte ordering &quot;Little Endian&quot; (MostSignificantByteLast) and &quot;Big Endian&quot; (MostSignificantByteFirst) can be selected. 
The value of this attribute impacts the absolute position of the signal into the PDU (see the startPosition attribute description).

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="START-POSITION" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			This parameter is necessary to describe the position of a signal within a PDU or SubPDU.
It denotes the least significant bit for &quot;Little Endian&quot; and the most significant bit for &quot;Big Endian&quot; packed signals within the PDU (see the description of the packingByteOrder attribute).

Bits within the PDU are counted as follows (see the OSEK COM v3.0.3 specification) :
      Bit 0 corresponds to Byte 0 Bit 0
      Bit 1 corresponds to Byte 0 Bit 1
      .....
      Bit 8 corresponds to Byte 1 Bit 0
      etc.

Please note that the way the bytes will be actually sent on the bus does not impact this representation: they will always be seen by the software as a byte array. 
Note also that the absolute position of the signal in the PDU is then determined by the definition of the packingByteOrder attribute of the signal.

		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="SYSTEM-SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class PDUStructure::SignalPosition -->
	<xsd:complexType name="SIGNAL-POSITION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The signal position defines which system signal is transmitted at which position within the aggregating PDU. The SignalPosition must be defined within a PDU or a SubPDU.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SIGNAL-POSITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SIGNAL-POSITION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SIGNAL-POSITION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class SWmapping::AggregatedStackUsage -->
	<xsd:complexType name="AGGREGATED-STACK-USAGE" abstract="false" mixed="false">
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class SWmapping::BSWResourceEstimation -->
	<xsd:complexType name="BSW-RESOURCE-ESTIMATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Estimations for the resource consumption for the basic software.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:RESOURCE-ESTIMATION-DETAILS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SWmapping::ResourceEstimationDetails -->
	<xsd:group name="RESOURCE-ESTIMATION-DETAILS">
		<xsd:annotation>
			<xsd:documentation>
			Abstract class that generalizes BSWResourceEstimatin and RTEResourceEstimation. Used to define common aggregated elements.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="HEAP-USAGES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MEASURED-HEAP-USAGE" type="AR:MEASURED-HEAP-USAGE"/>
						<xsd:element name="ROUGH-ESTIMATE-HEAP-USAGE" type="AR:ROUGH-ESTIMATE-HEAP-USAGE"/>
						<xsd:element name="WORST-CASE-HEAP-USAGE" type="AR:WORST-CASE-HEAP-USAGE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="STACK-USAGES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="AGGREGATED-STACK-USAGE" type="AR:AGGREGATED-STACK-USAGE"/>
						<xsd:element name="MEASURED-STACK-USAGE" type="AR:MEASURED-STACK-USAGE"/>
						<xsd:element name="ROUGH-ESTIMATE-STACK-USAGE" type="AR:ROUGH-ESTIMATE-STACK-USAGE"/>
						<xsd:element name="WORST-CASE-STACK-USAGE" type="AR:WORST-CASE-STACK-USAGE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class SWmapping::ComponentCluster -->
	<xsd:group name="COMPONENT-CLUSTER">
		<xsd:annotation>
			<xsd:documentation>
			Constraint that forces the mapping of all referenced SW component instances to the same ECU
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CLUSTERED-COMPONENT-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLUSTERED-COMPONENT-IREF" type="AR:COMPONENT-CLUSTER--CLUSTERED-COMPONENT-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SWmapping::ComponentCluster -->
	<xsd:complexType name="COMPONENT-CLUSTER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Constraint that forces the mapping of all referenced SW component instances to the same ECU
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:COMPONENT-CLUSTER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SWmapping::ComponentSeparation -->
	<xsd:group name="COMPONENT-SEPARATION">
		<xsd:annotation>
			<xsd:documentation>
			Constraint that forces the two referenced SW components (called A and B in the following) not to be mapped to the same ECU. If a SW component (e.g. A) is a composition, none of the atomic SW components making up the A composition must be mapped together with any of the atomic SW components making up the B composition. Furthermore, A and B must be disjoint. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SEPARATED-COMPONENT-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="2">
						<xsd:element name="SEPARATED-COMPONENT-IREF" type="AR:COMPONENT-SEPARATION--SEPARATED-COMPONENT-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SWmapping::ComponentSeparation -->
	<xsd:complexType name="COMPONENT-SEPARATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Constraint that forces the two referenced SW components (called A and B in the following) not to be mapped to the same ECU. If a SW component (e.g. A) is a composition, none of the atomic SW components making up the A composition must be mapped together with any of the atomic SW components making up the B composition. Furthermore, A and B must be disjoint. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:COMPONENT-SEPARATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SWmapping::EcuResourceEstimation -->
	<xsd:group name="ECU-RESOURCE-ESTIMATION">
		<xsd:annotation>
			<xsd:documentation>
			Resource estimations for RTE and BSW of a single ECU instance,

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="BSW-RESOURCE-ESTIMATION" type="AR:BSW-RESOURCE-ESTIMATION" minOccurs="0"/>
			<xsd:element name="ECU-INSTANCE-IREF" type="AR:ECU-RESOURCE-ESTIMATION--ECU-INSTANCE-IREF" minOccurs="0"/>
			<xsd:element name="RTE-RESSOURCE-ESTIMATION" type="AR:RTE-RESSOURCE-ESTIMATION" minOccurs="0"/>
			<xsd:element name="SW-COMP-TO-ECU-MAPPING-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SW-COMP-TO-ECU-MAPPING-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:SW-COMP-TO-ECU-MAPPING--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SWmapping::EcuResourceEstimation -->
	<xsd:complexType name="ECU-RESOURCE-ESTIMATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Resource estimations for RTE and BSW of a single ECU instance,

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:ECU-RESOURCE-ESTIMATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SWmapping::SwCompToEcuMapping -->
	<xsd:group name="SW-COMP-TO-ECU-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			Map software components to a specific ECU
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMPONENT-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMPONENT-IREF" type="AR:SW-COMP-TO-ECU-MAPPING--COMPONENT-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-INSTANCE-IREF" type="AR:SW-COMP-TO-ECU-MAPPING--ECU-INSTANCE-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SWmapping::SwCompToEcuMapping -->
	<xsd:complexType name="SW-COMP-TO-ECU-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Map software components to a specific ECU
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SW-COMP-TO-ECU-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="SW-COMP-TO-ECU-MAPPING--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="SW-COMP-TO-ECU-MAPPING"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- complex type for class SWmapping::RTERessourceEstimation -->
	<xsd:complexType name="RTE-RESSOURCE-ESTIMATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Estimations for the resource consumption for the AUTOSAR run time environment.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:RESOURCE-ESTIMATION-DETAILS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SWmapping::FreeTextMappingConstraint -->
	<xsd:group name="FREE-TEXT-MAPPING-CONSTRAINT">
		<xsd:annotation>
			<xsd:documentation>
			Constraints in natural language that cannot be expressed with the other  constraints. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONSTRAINT-EXPRESSION" type="xsd:string" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SWmapping::FreeTextMappingConstraint -->
	<xsd:complexType name="FREE-TEXT-MAPPING-CONSTRAINT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Constraints in natural language that cannot be expressed with the other  constraints. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:FREE-TEXT-MAPPING-CONSTRAINT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SWmapping::SwCompToImplMapping -->
	<xsd:group name="SW-COMP-TO-IMPL-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			Map instances of an AtomicSoftwareComponentType to a specific Implementation.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMPONENT-IMPLEMENTATION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:IMPLEMENTATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMPONENT-IREF" type="AR:SW-COMP-TO-IMPL-MAPPING--COMPONENT-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SWmapping::SwCompToImplMapping -->
	<xsd:complexType name="SW-COMP-TO-IMPL-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Map instances of an AtomicSoftwareComponentType to a specific Implementation.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:SW-COMP-TO-IMPL-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ComponentCluster_clusteredComponent -->
	<xsd:group name="COMPONENT-CLUSTER--CLUSTERED-COMPONENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CLUSTERED-COMPONENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ComponentCluster_clusteredComponent -->
	<xsd:complexType name="COMPONENT-CLUSTER--CLUSTERED-COMPONENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPONENT-CLUSTER--CLUSTERED-COMPONENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ComponentSeparation_separatedComponent -->
	<xsd:group name="COMPONENT-SEPARATION--SEPARATED-COMPONENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SEPARATED-COMPONENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ComponentSeparation_separatedComponent -->
	<xsd:complexType name="COMPONENT-SEPARATION--SEPARATED-COMPONENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMPONENT-SEPARATION--SEPARATED-COMPONENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::EcuResourceEstimation_ecuInstance -->
	<xsd:group name="ECU-RESOURCE-ESTIMATION--ECU-INSTANCE-IREF">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-INSTANCE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::EcuResourceEstimation_ecuInstance -->
	<xsd:complexType name="ECU-RESOURCE-ESTIMATION--ECU-INSTANCE-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:ECU-RESOURCE-ESTIMATION--ECU-INSTANCE-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SwCompToEcuMapping_component -->
	<xsd:group name="SW-COMP-TO-ECU-MAPPING--COMPONENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="TARGET-COMPONENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SwCompToEcuMapping_component -->
	<xsd:complexType name="SW-COMP-TO-ECU-MAPPING--COMPONENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SW-COMP-TO-ECU-MAPPING--COMPONENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SwCompToEcuMapping_ecuInstance -->
	<xsd:group name="SW-COMP-TO-ECU-MAPPING--ECU-INSTANCE-IREF">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-INSTANCE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SwCompToEcuMapping_ecuInstance -->
	<xsd:complexType name="SW-COMP-TO-ECU-MAPPING--ECU-INSTANCE-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SW-COMP-TO-ECU-MAPPING--ECU-INSTANCE-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SwCompToImplMapping_component -->
	<xsd:group name="SW-COMP-TO-IMPL-MAPPING--COMPONENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="TARGET-COMPONENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SwCompToImplMapping_component -->
	<xsd:complexType name="SW-COMP-TO-IMPL-MAPPING--COMPONENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SW-COMP-TO-IMPL-MAPPING--COMPONENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SignalPaths::CommonSignalPath -->
	<xsd:group name="COMMON-SIGNAL-PATH">
		<xsd:annotation>
			<xsd:documentation>
			The CommonSignalPath describes that two or more SwcToSwcSignals and/or SwcToSwcOperationArguments must take the same way (Signal Path) in the topology. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OPERATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SWC-TO-SWC-OPERATION-ARGUMENTS" type="AR:SWC-TO-SWC-OPERATION-ARGUMENTS"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIGNALS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SWC-TO-SWC-SIGNAL" type="AR:SWC-TO-SWC-SIGNAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SignalPaths::CommonSignalPath -->
	<xsd:complexType name="COMMON-SIGNAL-PATH" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The CommonSignalPath describes that two or more SwcToSwcSignals and/or SwcToSwcOperationArguments must take the same way (Signal Path) in the topology. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:COMMON-SIGNAL-PATH"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SignalPaths::SwcToSwcOperationArguments -->
	<xsd:group name="SWC-TO-SWC-OPERATION-ARGUMENTS">
		<xsd:annotation>
			<xsd:documentation>
			The SwcToSwcOperationArguments describes the information (client server operation arguments, plus the operation identification, if required) that are exchanged between two SW Components from exactly one client to one server, or from one server back to one client. The direction attribute defines which direction is described. If direction == IN, all arguments sent from the client to the server are described by the SwcToSwcOperationArguments, in direction == OUT, it&apos;s the arguments sent back from server to client.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DIRECTION" type="AR:SWC-TO-SWC-OPERATION-ARGUMENTS-DIRECTION-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			direction addressed by this SwcToSwcClientServerOperation element. Possible option are IN (all IN and INOUT arguments) and OUT (all OUT and INOUT arguments) .
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="OPERATION-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="2">
						<xsd:element name="OPERATION-IREF" type="AR:SWC-TO-SWC-OPERATION-ARGUMENTS--OPERATION-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SignalPaths::SwcToSwcOperationArguments -->
	<xsd:complexType name="SWC-TO-SWC-OPERATION-ARGUMENTS" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The SwcToSwcOperationArguments describes the information (client server operation arguments, plus the operation identification, if required) that are exchanged between two SW Components from exactly one client to one server, or from one server back to one client. The direction attribute defines which direction is described. If direction == IN, all arguments sent from the client to the server are described by the SwcToSwcOperationArguments, in direction == OUT, it&apos;s the arguments sent back from server to client.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SWC-TO-SWC-OPERATION-ARGUMENTS"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="SWC-TO-SWC-OPERATION-ARGUMENTS-DIRECTION-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="IN"/>
			<xsd:enumeration value="OUT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class SignalPaths::SwcToSwcSignal -->
	<xsd:group name="SWC-TO-SWC-SIGNAL">
		<xsd:annotation>
			<xsd:documentation>
			The SwcToSwcSignal describes the information (data element) that is exchanged between two SW Components. On the SWC Level it is possible that a SW Component sends one data element from one P-Port to two different SW Components (1:n Communication). The SwcToSwcSignal describes exactly the information which is exchanged between one P-Port of a SW Component and one R-Port of another SW Component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="2">
						<xsd:element name="DATA-ELEMENT-IREF" type="AR:SWC-TO-SWC-SIGNAL--DATA-ELEMENT-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SignalPaths::SwcToSwcSignal -->
	<xsd:complexType name="SWC-TO-SWC-SIGNAL" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The SwcToSwcSignal describes the information (data element) that is exchanged between two SW Components. On the SWC Level it is possible that a SW Component sends one data element from one P-Port to two different SW Components (1:n Communication). The SwcToSwcSignal describes exactly the information which is exchanged between one P-Port of a SW Component and one R-Port of another SW Component.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SWC-TO-SWC-SIGNAL"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SignalPaths::ForbiddenSignalPath -->
	<xsd:group name="FORBIDDEN-SIGNAL-PATH">
		<xsd:annotation>
			<xsd:documentation>
			The ForbiddenSignalPath describes the way (Signal Path) which an element must not take in the topology. Such a signal path can be a constraint for the communication matrix,  because such a path has an effect on the frame generation and the frame path.   
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ECU-COMMUNICATION-PORT-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ECU-COMMUNICATION-PORT-IREF" type="AR:FORBIDDEN-SIGNAL-PATH--ECU-COMMUNICATION-PORT-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OPERATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SWC-TO-SWC-OPERATION-ARGUMENTS" type="AR:SWC-TO-SWC-OPERATION-ARGUMENTS"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIGNALS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SWC-TO-SWC-SIGNAL" type="AR:SWC-TO-SWC-SIGNAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SignalPaths::ForbiddenSignalPath -->
	<xsd:complexType name="FORBIDDEN-SIGNAL-PATH" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The ForbiddenSignalPath describes the way (Signal Path) which an element must not take in the topology. Such a signal path can be a constraint for the communication matrix,  because such a path has an effect on the frame generation and the frame path.   
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:FORBIDDEN-SIGNAL-PATH"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SignalPaths::PermissibleSignalPath -->
	<xsd:group name="PERMISSIBLE-SIGNAL-PATH">
		<xsd:annotation>
			<xsd:documentation>
			The PermissibleSignalPath describes the way (Signal Path) a data element can take in the topology. If more than one PermissibleSignalPath is defined for the same signal/operation attributes, any of them can be chosen. Such a signal path can be a constraint for the  communication matrix . This path describes that one data element should take path A and not path B. This has an effect on the frame generation and the frame path.   
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ECU-COMMUNICATION-PORT-IREFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ECU-COMMUNICATION-PORT-IREF" type="AR:PERMISSIBLE-SIGNAL-PATH--ECU-COMMUNICATION-PORT-IREF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OPERATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SWC-TO-SWC-OPERATION-ARGUMENTS" type="AR:SWC-TO-SWC-OPERATION-ARGUMENTS"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIGNALS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SWC-TO-SWC-SIGNAL" type="AR:SWC-TO-SWC-SIGNAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SignalPaths::PermissibleSignalPath -->
	<xsd:complexType name="PERMISSIBLE-SIGNAL-PATH" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The PermissibleSignalPath describes the way (Signal Path) a data element can take in the topology. If more than one PermissibleSignalPath is defined for the same signal/operation attributes, any of them can be chosen. Such a signal path can be a constraint for the  communication matrix . This path describes that one data element should take path A and not path B. This has an effect on the frame generation and the frame path.   
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PERMISSIBLE-SIGNAL-PATH"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class SignalPaths::SeparateSignalPath -->
	<xsd:group name="SEPARATE-SIGNAL-PATH">
		<xsd:annotation>
			<xsd:documentation>
			The SeparateSignalPath describes that two SwcToSwcSignals and/or SwcToSwcOperationArguments must not take the same way (Signal Path) in the topology (e.g. Redundancy).

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="OPERATIONS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SWC-TO-SWC-OPERATION-ARGUMENTS" type="AR:SWC-TO-SWC-OPERATION-ARGUMENTS"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIGNALS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SWC-TO-SWC-SIGNAL" type="AR:SWC-TO-SWC-SIGNAL"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class SignalPaths::SeparateSignalPath -->
	<xsd:complexType name="SEPARATE-SIGNAL-PATH" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The SeparateSignalPath describes that two SwcToSwcSignals and/or SwcToSwcOperationArguments must not take the same way (Signal Path) in the topology (e.g. Redundancy).

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SEPARATE-SIGNAL-PATH"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class SignalPaths::SignalPathConstraint -->
	<xsd:complexType name="SIGNAL-PATH-CONSTRAINT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Additional guidelines for the System Generator, which specific way a signal between two Software Components should take in the network without defining in which frame and with which timing it is transmitted.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence/>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ForbiddenSignalPath_ecuCommunicationPort -->
	<xsd:group name="FORBIDDEN-SIGNAL-PATH--ECU-COMMUNICATION-PORT-IREF">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-COMMUNICATION-PORT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-COMMUNICATION-PORT-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ForbiddenSignalPath_ecuCommunicationPort -->
	<xsd:complexType name="FORBIDDEN-SIGNAL-PATH--ECU-COMMUNICATION-PORT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:FORBIDDEN-SIGNAL-PATH--ECU-COMMUNICATION-PORT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::PermissibleSignalPath_ecuCommunicationPort -->
	<xsd:group name="PERMISSIBLE-SIGNAL-PATH--ECU-COMMUNICATION-PORT-IREF">
		<xsd:sequence>
			<xsd:element name="SYSTEM-TOPOLOGY-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-TOPOLOGY-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-COMMUNICATION-PORT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-COMMUNICATION-PORT-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::PermissibleSignalPath_ecuCommunicationPort -->
	<xsd:complexType name="PERMISSIBLE-SIGNAL-PATH--ECU-COMMUNICATION-PORT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:PERMISSIBLE-SIGNAL-PATH--ECU-COMMUNICATION-PORT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SwcToSwcOperationArguments_operation -->
	<xsd:group name="SWC-TO-SWC-OPERATION-ARGUMENTS--OPERATION-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OPERATION-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OPERATION-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SwcToSwcOperationArguments_operation -->
	<xsd:complexType name="SWC-TO-SWC-OPERATION-ARGUMENTS--OPERATION-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SWC-TO-SWC-OPERATION-ARGUMENTS--OPERATION-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SwcToSwcSignal_dataElement -->
	<xsd:group name="SWC-TO-SWC-SIGNAL--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SwcToSwcSignal_dataElement -->
	<xsd:complexType name="SWC-TO-SWC-SIGNAL--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SWC-TO-SWC-SIGNAL--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::ApplicationErrorMapping -->
	<xsd:group name="APPLICATION-ERROR-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			In client server communication, the server may return any value within the application error range.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SYSTEM-SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::ApplicationErrorMapping -->
	<xsd:complexType name="APPLICATION-ERROR-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			In client server communication, the server may return any value within the application error range.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:APPLICATION-ERROR-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::ClientIdMapping -->
	<xsd:group name="CLIENT-ID-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			In case of a server on one ECU with multiple clients on other ECUs, the client server communication shall use different unique COM signals and signal groups for each client to allow the identification of the client associated with each system signal.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SYSTEM-SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::ClientIdMapping -->
	<xsd:complexType name="CLIENT-ID-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			In case of a server on one ECU with multiple clients on other ECUs, the client server communication shall use different unique COM signals and signal groups for each client to allow the identification of the client associated with each system signal.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-ID-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::ClientServerArrayElementMapping -->
	<xsd:group name="CLIENT-SERVER-ARRAY-ELEMENT-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			The ArrayElement may be a primitive one or a composite one. If the element is primitive, it will be mapped to the &quot;SystemSignal&quot; (multiplicity 1).
If the element is composite, there will be no mapping to the &quot;SystemSignal&quot; (multiplicity 0). In this case the &quot;ArrayElementMapping&quot; Element will aggregate the &quot;TypeMapping&quot; Element. In that way also the composite datatypes can be mapped to SystemSignals. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CLIENT-SERVER-ARRAY-ELEMENT-MAPPING-ARRAY-ELEMENT-IREF" type="AR:CLIENT-SERVER-ARRAY-ELEMENT-MAPPING--ARRAY-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="COMPLEX-TYPE-MAPPING" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0">
						<xsd:element name="CLIENT-SERVER-ARRAY-TYPE-MAPPING" type="AR:CLIENT-SERVER-ARRAY-TYPE-MAPPING"/>
						<xsd:element name="CLIENT-SERVER-RECORD-TYPE-MAPPING" type="AR:CLIENT-SERVER-RECORD-TYPE-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::ClientServerArrayElementMapping -->
	<xsd:complexType name="CLIENT-SERVER-ARRAY-ELEMENT-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The ArrayElement may be a primitive one or a composite one. If the element is primitive, it will be mapped to the &quot;SystemSignal&quot; (multiplicity 1).
If the element is composite, there will be no mapping to the &quot;SystemSignal&quot; (multiplicity 0). In this case the &quot;ArrayElementMapping&quot; Element will aggregate the &quot;TypeMapping&quot; Element. In that way also the composite datatypes can be mapped to SystemSignals. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-ARRAY-ELEMENT-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::ClientServerArrayTypeMapping -->
	<xsd:group name="CLIENT-SERVER-ARRAY-TYPE-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			If the compositeType is an Array, the &quot;ArrayTypeMapping&quot; will be used. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ARRAY-ELEMENT-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLIENT-SERVER-ARRAY-ELEMENT-MAPPING" type="AR:CLIENT-SERVER-ARRAY-ELEMENT-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::ClientServerArrayTypeMapping -->
	<xsd:complexType name="CLIENT-SERVER-ARRAY-TYPE-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			If the compositeType is an Array, the &quot;ArrayTypeMapping&quot; will be used. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-ARRAY-TYPE-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::ClientServerPrimitiveTypeMapping -->
	<xsd:group name="CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of an argument with a primitive datatype to a signal. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ARGUMENT-IREF" type="AR:CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING--ARGUMENT-IREF" minOccurs="0"/>
			<xsd:element name="SYSTEM-SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::ClientServerPrimitiveTypeMapping -->
	<xsd:complexType name="CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of an argument with a primitive datatype to a signal. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::ClientServerRecordElementMapping -->
	<xsd:group name="CLIENT-SERVER-RECORD-ELEMENT-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of a primitive record element to a SystemSignal. 

If the element is composite, there will be no mapping (multiplicity 0). In this case the &quot;RecordElementMapping&quot; Element will aggregate the &quot;TypeMapping&quot; Element. In that way also the composite datatypes can be mapped to SystemSignals. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMPLEX-TYPE-MAPPING" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0">
						<xsd:element name="CLIENT-SERVER-ARRAY-TYPE-MAPPING" type="AR:CLIENT-SERVER-ARRAY-TYPE-MAPPING"/>
						<xsd:element name="CLIENT-SERVER-RECORD-TYPE-MAPPING" type="AR:CLIENT-SERVER-RECORD-TYPE-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RECORD-ELEMENT-IREF" type="AR:CLIENT-SERVER-RECORD-ELEMENT-MAPPING--RECORD-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::ClientServerRecordElementMapping -->
	<xsd:complexType name="CLIENT-SERVER-RECORD-ELEMENT-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of a primitive record element to a SystemSignal. 

If the element is composite, there will be no mapping (multiplicity 0). In this case the &quot;RecordElementMapping&quot; Element will aggregate the &quot;TypeMapping&quot; Element. In that way also the composite datatypes can be mapped to SystemSignals. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-RECORD-ELEMENT-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::ClientServerRecordTypeMapping -->
	<xsd:group name="CLIENT-SERVER-RECORD-TYPE-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			If the compositeType is a Record, the &quot;RecordTypeMapping&quot; will be used. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="RECORD-ELEMENT-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLIENT-SERVER-RECORD-ELEMENT-MAPPING" type="AR:CLIENT-SERVER-RECORD-ELEMENT-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::ClientServerRecordTypeMapping -->
	<xsd:complexType name="CLIENT-SERVER-RECORD-TYPE-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			If the compositeType is a Record, the &quot;RecordTypeMapping&quot; will be used. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-RECORD-TYPE-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::ClientServerToSignalGroupMapping -->
	<xsd:group name="CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of client server operation arguments to signals of a signal group. Arguments with a primitive datatype will be mapped via the &quot;ClientServerPrimitiveTypeMapping&quot; element. 
Arguments with composite datatypes will be mapped via the &quot;CompositeTypeMapping&quot; element. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="APPLICATION-ERRORS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="APPLICATION-ERROR-MAPPING" type="AR:APPLICATION-ERROR-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CLIENT-ID" type="AR:CLIENT-ID-MAPPING" minOccurs="0"/>
			<xsd:element name="COMPOSITE-TYPE-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLIENT-SERVER-ARRAY-TYPE-MAPPING" type="AR:CLIENT-SERVER-ARRAY-TYPE-MAPPING"/>
						<xsd:element name="CLIENT-SERVER-RECORD-TYPE-MAPPING" type="AR:CLIENT-SERVER-RECORD-TYPE-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="EMPTY-SIGNAL" type="AR:EMPTY-SIGNAL-MAPPING" minOccurs="0"/>
			<xsd:element name="MAPPED-OPERATION-IREF" type="AR:CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING--MAPPED-OPERATION-IREF" minOccurs="0"/>
			<xsd:element name="PRIMITIVE-TYPE-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING" type="AR:CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="REQUEST-GROUP-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL-GROUP--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RESPONSE-GROUP-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL-GROUP--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SEQUENCE-COUNTER" type="AR:SEQUENCE-COUNTER-MAPPING" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::ClientServerToSignalGroupMapping -->
	<xsd:complexType name="CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of client server operation arguments to signals of a signal group. Arguments with a primitive datatype will be mapped via the &quot;ClientServerPrimitiveTypeMapping&quot; element. 
Arguments with composite datatypes will be mapped via the &quot;CompositeTypeMapping&quot; element. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::EmptySignalMapping -->
	<xsd:group name="EMPTY-SIGNAL-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			According to the COM Specification, signal groups without signals are allowed. These have a &quot;signalLength&quot; = 0. In this case there shall be an &quot;update-bit&quot; configured.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SYSTEM-SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::EmptySignalMapping -->
	<xsd:complexType name="EMPTY-SIGNAL-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			According to the COM Specification, signal groups without signals are allowed. These have a &quot;signalLength&quot; = 0. In this case there shall be an &quot;update-bit&quot; configured.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:EMPTY-SIGNAL-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::SequenceCounterMapping -->
	<xsd:group name="SEQUENCE-COUNTER-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			The purpose of sequence counters is to map a response to the correct request of a known client.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SYSTEM-SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::SequenceCounterMapping -->
	<xsd:complexType name="SEQUENCE-COUNTER-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The purpose of sequence counters is to map a response to the correct request of a known client.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SEQUENCE-COUNTER-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::SenderRecArrayElementMapping -->
	<xsd:group name="SENDER-REC-ARRAY-ELEMENT-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			The ArrayElement may be a primitive one or a composite one. If the element is primitive, it will be mapped to the &quot;SystemSignal&quot; (multiplicity 1).
If the element is composite, there will be no mapping to the &quot;SystemSignal&quot; (multiplicity 0). In this case the &quot;ArrayElementMapping&quot; Element will aggregate the &quot;TypeMapping&quot; Element. In that way also the composite datatypes can be mapped to SystemSignals. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ARRAY-ELEMENT-IREF" type="AR:SENDER-REC-ARRAY-ELEMENT-MAPPING--ARRAY-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="COMPLEX-TYPE-MAPPING" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0">
						<xsd:element name="SENDER-REC-ARRAY-TYPE-MAPPING" type="AR:SENDER-REC-ARRAY-TYPE-MAPPING"/>
						<xsd:element name="SENDER-REC-RECORD-TYPE-MAPPING" type="AR:SENDER-REC-RECORD-TYPE-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::SenderRecArrayElementMapping -->
	<xsd:complexType name="SENDER-REC-ARRAY-ELEMENT-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The ArrayElement may be a primitive one or a composite one. If the element is primitive, it will be mapped to the &quot;SystemSignal&quot; (multiplicity 1).
If the element is composite, there will be no mapping to the &quot;SystemSignal&quot; (multiplicity 0). In this case the &quot;ArrayElementMapping&quot; Element will aggregate the &quot;TypeMapping&quot; Element. In that way also the composite datatypes can be mapped to SystemSignals. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-REC-ARRAY-ELEMENT-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::SenderRecArrayTypeMapping -->
	<xsd:group name="SENDER-REC-ARRAY-TYPE-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			If the compositeType is an Array, the &quot;ArrayTypeMapping&quot; will be used. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ARRAY-ELEMENT-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SENDER-REC-ARRAY-ELEMENT-MAPPING" type="AR:SENDER-REC-ARRAY-ELEMENT-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::SenderRecArrayTypeMapping -->
	<xsd:complexType name="SENDER-REC-ARRAY-TYPE-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			If the compositeType is an Array, the &quot;ArrayTypeMapping&quot; will be used. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-REC-ARRAY-TYPE-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::SenderReceiverToSignalGroupMapping -->
	<xsd:group name="SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of a sender receiver communication data element with a composite datatype to a signal group.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREF" type="AR:SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING--DATA-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="SIGNAL-GROUP-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL-GROUP--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="TYPE-MAPPING" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0">
						<xsd:element name="SENDER-REC-ARRAY-TYPE-MAPPING" type="AR:SENDER-REC-ARRAY-TYPE-MAPPING"/>
						<xsd:element name="SENDER-REC-RECORD-TYPE-MAPPING" type="AR:SENDER-REC-RECORD-TYPE-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::SenderReceiverToSignalGroupMapping -->
	<xsd:complexType name="SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of a sender receiver communication data element with a composite datatype to a signal group.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::SenderReceiverToSignalMapping -->
	<xsd:group name="SENDER-RECEIVER-TO-SIGNAL-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of a sender receiver communication data element with a primitive datatype to a signal. If the data element has to be transmitted in several signals (e.g. if the data is sent out to different receivers in different signals), one have to define several mappings. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DATA-ELEMENT-IREF" type="AR:SENDER-RECEIVER-TO-SIGNAL-MAPPING--DATA-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::SenderReceiverToSignalMapping -->
	<xsd:complexType name="SENDER-RECEIVER-TO-SIGNAL-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of a sender receiver communication data element with a primitive datatype to a signal. If the data element has to be transmitted in several signals (e.g. if the data is sent out to different receivers in different signals), one have to define several mappings. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-RECEIVER-TO-SIGNAL-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::SenderRecRecordElementMapping -->
	<xsd:group name="SENDER-REC-RECORD-ELEMENT-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of a primitive record element to a SystemSignal. 

If the element is composite, there will be no mapping (multiplicity 0). In this case the &quot;RecordElementMapping&quot; Element will aggregate the &quot;TypeMapping&quot; Element. In that way also the composite datatypes can be mapped to SystemSignals. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="COMPLEX-TYPE-MAPPING" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0">
						<xsd:element name="SENDER-REC-ARRAY-TYPE-MAPPING" type="AR:SENDER-REC-ARRAY-TYPE-MAPPING"/>
						<xsd:element name="SENDER-REC-RECORD-TYPE-MAPPING" type="AR:SENDER-REC-RECORD-TYPE-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RECORD-ELEMENT-IREF" type="AR:SENDER-REC-RECORD-ELEMENT-MAPPING--RECORD-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="SIGNAL-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::SenderRecRecordElementMapping -->
	<xsd:complexType name="SENDER-REC-RECORD-ELEMENT-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Mapping of a primitive record element to a SystemSignal. 

If the element is composite, there will be no mapping (multiplicity 0). In this case the &quot;RecordElementMapping&quot; Element will aggregate the &quot;TypeMapping&quot; Element. In that way also the composite datatypes can be mapped to SystemSignals. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-REC-RECORD-ELEMENT-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class DataMapping::SenderRecRecordTypeMapping -->
	<xsd:group name="SENDER-REC-RECORD-TYPE-MAPPING">
		<xsd:annotation>
			<xsd:documentation>
			If the compositeType is a Record, the &quot;RecordTypeMapping&quot; will be used. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="RECORD-ELEMENT-MAPPINGS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="SENDER-REC-RECORD-ELEMENT-MAPPING" type="AR:SENDER-REC-RECORD-ELEMENT-MAPPING"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class DataMapping::SenderRecRecordTypeMapping -->
	<xsd:complexType name="SENDER-REC-RECORD-TYPE-MAPPING" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			If the compositeType is a Record, the &quot;RecordTypeMapping&quot; will be used. 
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-REC-RECORD-TYPE-MAPPING"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ClientServerArrayElementMapping_arrayElement -->
	<xsd:group name="CLIENT-SERVER-ARRAY-ELEMENT-MAPPING--ARRAY-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ARGUMENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ARGUMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="NESTING-DATA-PROTOTYPE-MREF" type="AR:INDEXED-DATA-PROTOTYPE" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element name="ARRAY-ELEMENT-MREF" type="AR:INDEXED-ARRAY-ELEMENT"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ClientServerArrayElementMapping_arrayElement -->
	<xsd:complexType name="CLIENT-SERVER-ARRAY-ELEMENT-MAPPING--ARRAY-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-ARRAY-ELEMENT-MAPPING--ARRAY-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::IndexedDataPrototype -->
	<xsd:group name="INDEXED-DATA-PROTOTYPE">
		<xsd:sequence>
			<xsd:element name="INDEX" type="xsd:integer" minOccurs="0"/>
			<xsd:element name="NESTING-DATA-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::IndexedDataPrototype -->
	<xsd:complexType name="INDEXED-DATA-PROTOTYPE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:INDEXED-DATA-PROTOTYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::IndexedArrayElement -->
	<xsd:group name="INDEXED-ARRAY-ELEMENT">
		<xsd:sequence>
			<xsd:element name="INDEX" type="xsd:integer" minOccurs="0"/>
			<xsd:element name="ARRAY-ELEMENT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ARRAY-ELEMENT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::IndexedArrayElement -->
	<xsd:complexType name="INDEXED-ARRAY-ELEMENT" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:INDEXED-ARRAY-ELEMENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ClientServerPrimitiveTypeMapping_argument -->
	<xsd:group name="CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING--ARGUMENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ARGUMENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ARGUMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ClientServerPrimitiveTypeMapping_argument -->
	<xsd:complexType name="CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING--ARGUMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-PRIMITIVE-TYPE-MAPPING--ARGUMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ClientServerRecordElementMapping_recordElement -->
	<xsd:group name="CLIENT-SERVER-RECORD-ELEMENT-MAPPING--RECORD-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ARGUMENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ARGUMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="NESTING-DATA-PROTOTYPE-MREF" type="AR:INDEXED-DATA-PROTOTYPE" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element name="RECORD-ELEMENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:RECORD-ELEMENT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ClientServerRecordElementMapping_recordElement -->
	<xsd:complexType name="CLIENT-SERVER-RECORD-ELEMENT-MAPPING--RECORD-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-RECORD-ELEMENT-MAPPING--RECORD-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::ClientServerToSignalGroupMapping_mappedOperation -->
	<xsd:group name="CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING--MAPPED-OPERATION-IREF">
		<xsd:sequence>
			<xsd:element name="COMPOSITION-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="OPERATION-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:OPERATION-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::ClientServerToSignalGroupMapping_mappedOperation -->
	<xsd:complexType name="CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING--MAPPED-OPERATION-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:CLIENT-SERVER-TO-SIGNAL-GROUP-MAPPING--MAPPED-OPERATION-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SenderRecArrayElementMapping_arrayElement -->
	<xsd:group name="SENDER-REC-ARRAY-ELEMENT-MAPPING--ARRAY-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="NESTING-DATA-PROTOTYPE-MREF" type="AR:INDEXED-DATA-PROTOTYPE" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element name="ARRAY-ELEMENT-MREF" type="AR:INDEXED-ARRAY-ELEMENT"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SenderRecArrayElementMapping_arrayElement -->
	<xsd:complexType name="SENDER-REC-ARRAY-ELEMENT-MAPPING--ARRAY-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-REC-ARRAY-ELEMENT-MAPPING--ARRAY-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SenderReceiverToSignalGroupMapping_dataElement -->
	<xsd:group name="SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SenderReceiverToSignalGroupMapping_dataElement -->
	<xsd:complexType name="SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-RECEIVER-TO-SIGNAL-GROUP-MAPPING--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SenderReceiverToSignalMapping_dataElement -->
	<xsd:group name="SENDER-RECEIVER-TO-SIGNAL-MAPPING--DATA-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SenderReceiverToSignalMapping_dataElement -->
	<xsd:complexType name="SENDER-RECEIVER-TO-SIGNAL-MAPPING--DATA-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-RECEIVER-TO-SIGNAL-MAPPING--DATA-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::SenderRecRecordElementMapping_recordElement -->
	<xsd:group name="SENDER-REC-RECORD-ELEMENT-MAPPING--RECORD-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="SOFTWARE-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SOFTWARE-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMPONENT-PROTOTYPE-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMPONENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PORT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PORT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="DATA-ELEMENT-PROTOTYPE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:DATA-ELEMENT-PROTOTYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="NESTING-DATA-PROTOTYPE-MREF" type="AR:INDEXED-DATA-PROTOTYPE" minOccurs="0" maxOccurs="unbounded"/>
			<xsd:element name="RECORD-ELEMENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:RECORD-ELEMENT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::SenderRecRecordElementMapping_recordElement -->
	<xsd:complexType name="SENDER-REC-RECORD-ELEMENT-MAPPING--RECORD-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:SENDER-REC-RECORD-ELEMENT-MAPPING--RECORD-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class CommunicationProtocol::CommProtocolElement -->
	<xsd:group name="COMM-PROTOCOL-ELEMENT">
		<xsd:annotation>
			<xsd:documentation>
			Description of the protocol elements. These may be frames, signals (which are in turn part of a  frame) or signal groups.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DIRECTION" type="AR:COMM-PROTOCOL-ELEMENT-DIRECTION-ENUM" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The direction in which the element is sent-
s2r : Sender To Receiver (For Sender-Receiver Communication, e.g. data elements)
r2s: Receiver To Sender (For Sender-Receiver Communication, e.g. Acknowledgements)
c2s: Client to Server (For Client-Server Communication,  &quot;in&quot; parameters)
s2c Server to Client (For Client-Server Communication,  &quot;out&quot; parameters)
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CommunicationProtocol::CommProtocolElement -->
	<xsd:complexType name="COMM-PROTOCOL-ELEMENT" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Description of the protocol elements. These may be frames, signals (which are in turn part of a  frame) or signal groups.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMM-PROTOCOL-ELEMENT"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMM-PROTOCOL-ELEMENT--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMM-PROTOCOL-ELEMENT"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="COMM-PROTOCOL-ELEMENT-DIRECTION-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="S-2-R"/>
			<xsd:enumeration value="R-2-S"/>
			<xsd:enumeration value="C-2-S"/>
			<xsd:enumeration value="S-2-C"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class CommunicationProtocol::CommProtocolFrameRole -->
	<xsd:group name="COMM-PROTOCOL-FRAME-ROLE">
		<xsd:annotation>
			<xsd:documentation>
			If the protocol instance uses frame instances as protocol elements, they are specified with this element. This is e.g. the case in protocol ISO 15765-2, where complete frames are used to exchange information between the communication partners.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="FRAME-INSTANCE-IREF" type="AR:COMM-PROTOCOL-FRAME-ROLE--FRAME-INSTANCE-IREF" minOccurs="0"/>
			<xsd:element name="PROTOCOL-ELEMENT-IREF" type="AR:COMM-PROTOCOL-FRAME-ROLE--PROTOCOL-ELEMENT-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CommunicationProtocol::CommProtocolFrameRole -->
	<xsd:complexType name="COMM-PROTOCOL-FRAME-ROLE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			If the protocol instance uses frame instances as protocol elements, they are specified with this element. This is e.g. the case in protocol ISO 15765-2, where complete frames are used to exchange information between the communication partners.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMM-PROTOCOL-FRAME-ROLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class CommunicationProtocol::CommProtocolSignalGroupRole -->
	<xsd:group name="COMM-PROTOCOL-SIGNAL-GROUP-ROLE">
		<xsd:annotation>
			<xsd:documentation>
			If the protocol instance uses signal groups as protocol elements, they are specified with this element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PROTOCOL-ELEMENT-IREF" type="AR:COMM-PROTOCOL-SIGNAL-GROUP-ROLE--PROTOCOL-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="SIGNAL-GROUP-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL-GROUP--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CommunicationProtocol::CommProtocolSignalGroupRole -->
	<xsd:complexType name="COMM-PROTOCOL-SIGNAL-GROUP-ROLE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			If the protocol instance uses signal groups as protocol elements, they are specified with this element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMM-PROTOCOL-SIGNAL-GROUP-ROLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class CommunicationProtocol::CommProtocolSignalRole -->
	<xsd:group name="COMM-PROTOCOL-SIGNAL-ROLE">
		<xsd:annotation>
			<xsd:documentation>
			If the protocol instance uses signal instances (in a specific frame instance) as protocol elements, they are specified with this element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PROTOCOL-ELEMENT-IREF" type="AR:COMM-PROTOCOL-SIGNAL-ROLE--PROTOCOL-ELEMENT-IREF" minOccurs="0"/>
			<xsd:element name="SIGNAL-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM-SIGNAL--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CommunicationProtocol::CommProtocolSignalRole -->
	<xsd:complexType name="COMM-PROTOCOL-SIGNAL-ROLE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			If the protocol instance uses signal instances (in a specific frame instance) as protocol elements, they are specified with this element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMM-PROTOCOL-SIGNAL-ROLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class CommunicationProtocol::CommProtocolType -->
	<xsd:group name="COMM-PROTOCOL-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			The protocol type description describes all necessary protocol parameters that are the same for all instances of the protocol and that are necessary to configure the protocol.,
This is e.g.. a generic definition of ISO 15765-2.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PROTOCOL-ELEMENTS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMM-PROTOCOL-ELEMENT" type="AR:COMM-PROTOCOL-ELEMENT"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CommunicationProtocol::CommProtocolType -->
	<xsd:complexType name="COMM-PROTOCOL-TYPE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			The protocol type description describes all necessary protocol parameters that are the same for all instances of the protocol and that are necessary to configure the protocol.,
This is e.g.. a generic definition of ISO 15765-2.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMM-PROTOCOL-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMM-PROTOCOL-TYPE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMM-PROTOCOL-TYPE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class CommunicationProtocol::CommProtocolInstance -->
	<xsd:group name="COMM-PROTOCOL-INSTANCE">
		<xsd:annotation>
			<xsd:documentation>
			An instance of a communication protocol, used for exchanging information between specific communication partners. This might e.g. be an instance of ISO 15765-2 running between ECU A and ECU B.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="PROTOCOL-FRAMES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMM-PROTOCOL-FRAME-ROLE" type="AR:COMM-PROTOCOL-FRAME-ROLE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROTOCOL-SIGNALS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMM-PROTOCOL-SIGNAL-ROLE" type="AR:COMM-PROTOCOL-SIGNAL-ROLE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROTOCOL-SIGNAL-GROUPS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="COMM-PROTOCOL-SIGNAL-GROUP-ROLE" type="AR:COMM-PROTOCOL-SIGNAL-GROUP-ROLE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROTOCOL-TYPE-TREF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMM-PROTOCOL-TYPE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class CommunicationProtocol::CommProtocolInstance -->
	<xsd:complexType name="COMM-PROTOCOL-INSTANCE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			An instance of a communication protocol, used for exchanging information between specific communication partners. This might e.g. be an instance of ISO 15765-2 running between ECU A and ECU B.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:COMM-PROTOCOL-INSTANCE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="COMM-PROTOCOL-INSTANCE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="COMM-PROTOCOL-INSTANCE"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class _instanceRef::CommProtocolFrameRole_frameInstance -->
	<xsd:group name="COMM-PROTOCOL-FRAME-ROLE--FRAME-INSTANCE-IREF">
		<xsd:sequence>
			<xsd:element name="COMMUNICATION-MATRIX-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMMUNICATION-MATRIX-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="FRAME-INSTANCE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:FRAME--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::CommProtocolFrameRole_frameInstance -->
	<xsd:complexType name="COMM-PROTOCOL-FRAME-ROLE--FRAME-INSTANCE-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMM-PROTOCOL-FRAME-ROLE--FRAME-INSTANCE-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::CommProtocolFrameRole_protocolElement -->
	<xsd:group name="COMM-PROTOCOL-FRAME-ROLE--PROTOCOL-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="COMM-PROTOCOL-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMM-PROTOCOL-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROTOCOL-ELEMENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMM-PROTOCOL-ELEMENT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::CommProtocolFrameRole_protocolElement -->
	<xsd:complexType name="COMM-PROTOCOL-FRAME-ROLE--PROTOCOL-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMM-PROTOCOL-FRAME-ROLE--PROTOCOL-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::CommProtocolSignalGroupRole_protocolElement -->
	<xsd:group name="COMM-PROTOCOL-SIGNAL-GROUP-ROLE--PROTOCOL-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="COMM-PROTOCOL-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMM-PROTOCOL-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="COMM-PROTOCOL-ELEMENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMM-PROTOCOL-ELEMENT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::CommProtocolSignalGroupRole_protocolElement -->
	<xsd:complexType name="COMM-PROTOCOL-SIGNAL-GROUP-ROLE--PROTOCOL-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMM-PROTOCOL-SIGNAL-GROUP-ROLE--PROTOCOL-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::CommProtocolSignalRole_protocolElement -->
	<xsd:group name="COMM-PROTOCOL-SIGNAL-ROLE--PROTOCOL-ELEMENT-IREF">
		<xsd:sequence>
			<xsd:element name="COMM-PROTOCOL-INSTANCE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMM-PROTOCOL-INSTANCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PROTOCOL-ELEMENT-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:COMM-PROTOCOL-ELEMENT--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::CommProtocolSignalRole_protocolElement -->
	<xsd:complexType name="COMM-PROTOCOL-SIGNAL-ROLE--PROTOCOL-ELEMENT-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:COMM-PROTOCOL-SIGNAL-ROLE--PROTOCOL-ELEMENT-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::BooleanParamDef -->
	<xsd:group name="BOOLEAN-PARAM-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Boolean. allowed values are true and false.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFAULT-VALUE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Default value of the boolean configuration parameter.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::BooleanParamDef -->
	<xsd:complexType name="BOOLEAN-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Boolean. allowed values are true and false.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:BOOLEAN-PARAM-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::ConfigParameter -->
	<xsd:group name="CONFIG-PARAMETER">
		<xsd:annotation>
			<xsd:documentation>
			Abstract class used to define the similarities of all ECU Configuration Parameter types defined as subclasses.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="SYMBOLIC-NAME-VALUE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies that this parameter&apos;s value is used, together with the aggregating container, to derive a symbolic name definition. E.g.: #define &quot;container_shortName&quot; &quot;this parameter&apos;s value&quot;.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="CONFIG-PARAMETER--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="BOOLEAN-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-BOOLEAN-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-ENUMERATION-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-FLOAT-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-INTEGER-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-STRING-PARAM-DEF"/>
			<xsd:enumeration value="ENUMERATION-PARAM-DEF"/>
			<xsd:enumeration value="FLOAT-PARAM-DEF"/>
			<xsd:enumeration value="FUNCTION-NAME-DEF"/>
			<xsd:enumeration value="INTEGER-PARAM-DEF"/>
			<xsd:enumeration value="LINKER-SYMBOL-DEF"/>
			<xsd:enumeration value="STRING-PARAM-DEF"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUCParameterDefTemplate::CommonConfigurationAttributes -->
	<xsd:group name="COMMON-CONFIGURATION-ATTRIBUTES">
		<xsd:annotation>
			<xsd:documentation>
			Attributes used by Configuration Parameters as well as References.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CONFIGURATION-CLASS-AFFECTION" type="AR:CONFIGURATION-CLASS-AFFECTION" minOccurs="0"/>
			<xsd:element name="IMPLEMENTATION-CONFIG-CLASS" type="AR:CONFIGURATION-CLASS" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifying the actual configuration class of a configuration parameter in the &quot;vendor specific module definition&quot; in which it is mandatory.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="ORIGIN" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			String specifying if this configuration parameter is an AUTOSAR standardized configuration parameter or if the parameter is hardware- or vendor-specific.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="COMMON-CONFIGURATION-ATTRIBUTES--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="BOOLEAN-PARAM-DEF"/>
			<xsd:enumeration value="CHOICE-REFERENCE-DEF"/>
			<xsd:enumeration value="DERIVED-BOOLEAN-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-ENUMERATION-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-FLOAT-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-INTEGER-PARAM-DEF"/>
			<xsd:enumeration value="DERIVED-STRING-PARAM-DEF"/>
			<xsd:enumeration value="ENUMERATION-PARAM-DEF"/>
			<xsd:enumeration value="FLOAT-PARAM-DEF"/>
			<xsd:enumeration value="FOREIGN-REFERENCE-DEF"/>
			<xsd:enumeration value="FUNCTION-NAME-DEF"/>
			<xsd:enumeration value="INSTANCE-REFERENCE-DEF"/>
			<xsd:enumeration value="INTEGER-PARAM-DEF"/>
			<xsd:enumeration value="LINKER-SYMBOL-DEF"/>
			<xsd:enumeration value="REFERENCE-DEF"/>
			<xsd:enumeration value="STRING-PARAM-DEF"/>
			<xsd:enumeration value="SYMBOLIC-NAME-REFERENCE-DEF"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUCParameterDefTemplate::ParamConfMultiplicity -->
	<xsd:group name="PARAM-CONF-MULTIPLICITY">
		<xsd:annotation>
			<xsd:documentation>
			Common class used to express multiplicities in the definition of configuration parameters and containers.
If not stated otherwise the default multiplicity is exactly one mandatory occurrence of the specified element.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="LOWER-MULTIPLICITY" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The lower multiplicity of the specified element.
0: optional
1: at least one occurence
n: at least n occurrences
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="UPPER-MULTIPLICITY" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The upper multiplicity of the specified element.
1: at most one occurrence
m: at most m occurrences
*: arbitrary number of occurrences
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<xsd:simpleType name="CONFIGURATION-CLASS">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="POST-BUILD-LOADABLE"/>
			<xsd:enumeration value="POST-BUILD"/>
			<xsd:enumeration value="PRE-COMPILE"/>
			<xsd:enumeration value="POST-BUILD-SELECTABLE"/>
			<xsd:enumeration value="PUBLISHED-INFORMATION"/>
			<xsd:enumeration value="LINK"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUCParameterDefTemplate::ConfigurationClassAffection -->
	<xsd:group name="CONFIGURATION-CLASS-AFFECTION">
		<xsd:annotation>
			<xsd:documentation>
			Specifies in the &quot;VendorSpecificModuleDefinition&quot; whether changes on this parameter do affect other parameters in a later configuration step.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="AFFECTED-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="AFFECTED-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:COMMON-CONFIGURATION-ATTRIBUTES--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="AFFECTION-KIND" type="AR:CONFIGURATION-AFFECTION" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::ConfigurationClassAffection -->
	<xsd:complexType name="CONFIGURATION-CLASS-AFFECTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specifies in the &quot;VendorSpecificModuleDefinition&quot; whether changes on this parameter do affect other parameters in a later configuration step.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CONFIGURATION-CLASS-AFFECTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<xsd:simpleType name="CONFIGURATION-AFFECTION">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PC-AFFECTS-PB"/>
			<xsd:enumeration value="PC-AFFECTS-LT"/>
			<xsd:enumeration value="PC-AFFECTS-LT-AND-PB"/>
			<xsd:enumeration value="NO-AFFECT"/>
			<xsd:enumeration value="LT-AFFECTS-PB"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="CALCULATION-LANGUAGE">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="INFORMAL"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUCParameterDefTemplate::ChoiceContainerDef -->
	<xsd:group name="CHOICE-CONTAINER-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Used to define configuration containers that provide a choice between several ParamConfContainerDef. But in the actual ECU Configuration Description only one instance from the choice list will be present (depending on the multiplicites given).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CHOICES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="PARAM-CONF-CONTAINER-DEF" type="AR:PARAM-CONF-CONTAINER-DEF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::ChoiceContainerDef -->
	<xsd:complexType name="CHOICE-CONTAINER-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Used to define configuration containers that provide a choice between several ParamConfContainerDef. But in the actual ECU Configuration Description only one instance from the choice list will be present (depending on the multiplicites given).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:CONTAINER-DEF"/>
			<xsd:group ref="AR:CHOICE-CONTAINER-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::ContainerDef -->
	<xsd:group name="CONTAINER-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Base class used to gather common attributes of configuration container definitions.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="POST-BUILD-CHANGEABLE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies if the number of instances of this container may be changed post-build time. This parameter may only be set to true if all of the following conditions hold:
- the container&apos;s upperMultiplicity &gt; lowerMultiplicity
- all parameters within the container and subContainers are post-build time changeable.
If any of the aggregated parameters is either pre-compile time or link time this attribute is ignored and may be omitted.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class ECUCParameterDefTemplate::ParamConfContainerDef -->
	<xsd:group name="PARAM-CONF-CONTAINER-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Used to define configuration containers that can hierarchically contain other containers and/or parameter definitions.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MULTIPLE-CONFIGURATION-CONTAINER" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Specifies whether this container is used to define multiple configuration sets. Only one container in the whole ModuleDef shall have this enabled.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PARAMETERS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="BOOLEAN-PARAM-DEF" type="AR:BOOLEAN-PARAM-DEF"/>
						<xsd:element name="DERIVED-BOOLEAN-PARAM-DEF" type="AR:DERIVED-BOOLEAN-PARAM-DEF"/>
						<xsd:element name="DERIVED-ENUMERATION-PARAM-DEF" type="AR:DERIVED-ENUMERATION-PARAM-DEF"/>
						<xsd:element name="DERIVED-FLOAT-PARAM-DEF" type="AR:DERIVED-FLOAT-PARAM-DEF"/>
						<xsd:element name="DERIVED-INTEGER-PARAM-DEF" type="AR:DERIVED-INTEGER-PARAM-DEF"/>
						<xsd:element name="DERIVED-STRING-PARAM-DEF" type="AR:DERIVED-STRING-PARAM-DEF"/>
						<xsd:element name="ENUMERATION-PARAM-DEF" type="AR:ENUMERATION-PARAM-DEF"/>
						<xsd:element name="FLOAT-PARAM-DEF" type="AR:FLOAT-PARAM-DEF"/>
						<xsd:element name="FUNCTION-NAME-DEF" type="AR:FUNCTION-NAME-DEF"/>
						<xsd:element name="INTEGER-PARAM-DEF" type="AR:INTEGER-PARAM-DEF"/>
						<xsd:element name="LINKER-SYMBOL-DEF" type="AR:LINKER-SYMBOL-DEF"/>
						<xsd:element name="STRING-PARAM-DEF" type="AR:STRING-PARAM-DEF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="REFERENCES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CHOICE-REFERENCE-DEF" type="AR:CHOICE-REFERENCE-DEF"/>
						<xsd:element name="FOREIGN-REFERENCE-DEF" type="AR:FOREIGN-REFERENCE-DEF"/>
						<xsd:element name="INSTANCE-REFERENCE-DEF" type="AR:INSTANCE-REFERENCE-DEF"/>
						<xsd:element name="REFERENCE-DEF" type="AR:REFERENCE-DEF"/>
						<xsd:element name="SYMBOLIC-NAME-REFERENCE-DEF" type="AR:SYMBOLIC-NAME-REFERENCE-DEF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SUB-CONTAINERS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CHOICE-CONTAINER-DEF" type="AR:CHOICE-CONTAINER-DEF"/>
						<xsd:element name="PARAM-CONF-CONTAINER-DEF" type="AR:PARAM-CONF-CONTAINER-DEF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::ParamConfContainerDef -->
	<xsd:complexType name="PARAM-CONF-CONTAINER-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Used to define configuration containers that can hierarchically contain other containers and/or parameter definitions.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:CONTAINER-DEF"/>
			<xsd:group ref="AR:PARAM-CONF-CONTAINER-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="PARAM-CONF-CONTAINER-DEF--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="PARAM-CONF-CONTAINER-DEF"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="CONFIG-REFERENCE--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="CHOICE-REFERENCE-DEF"/>
			<xsd:enumeration value="FOREIGN-REFERENCE-DEF"/>
			<xsd:enumeration value="INSTANCE-REFERENCE-DEF"/>
			<xsd:enumeration value="REFERENCE-DEF"/>
			<xsd:enumeration value="SYMBOLIC-NAME-REFERENCE-DEF"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUCParameterDefTemplate::ChoiceReferenceDef -->
	<xsd:group name="CHOICE-REFERENCE-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Specify alternative references where in the ECU Configuration description only one of the specified references will actually be used.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DESTINATION-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="DESTINATION-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:PARAM-CONF-CONTAINER-DEF--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::ChoiceReferenceDef -->
	<xsd:complexType name="CHOICE-REFERENCE-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specify alternative references where in the ECU Configuration description only one of the specified references will actually be used.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CHOICE-REFERENCE-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ECUCParameterDefTemplate::DerivedBooleanParamDef -->
	<xsd:complexType name="DERIVED-BOOLEAN-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Derived value is of type Boolean
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:BOOLEAN-PARAM-DEF"/>
			<xsd:group ref="AR:DERIVED-PARAM-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::DerivedParamType -->
	<xsd:group name="DERIVED-PARAM-TYPE">
		<xsd:annotation>
			<xsd:documentation>
			Allows to define configuration items that are calculated based on the value of 
* other parameters values
* elements (attributes /classes) defined in other AUTOSAR templates such as System template and SW component template.
For these definitions there is no corresponding entry in the ECUC description. Instead, a calculation definition is given that defines how Configuration Editors and Generators can calculate the value from other values when needed to display/use the configuration item 
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="40"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="CALCULATION-FORMULA" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Definition of the formula used to calculate the value of the configuration element.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="CALCULATION-LANGUAGE" type="AR:CALCULATION-LANGUAGE" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Definition of the languag used to specify the formula in attribute calculationFormula.
Currentlfy, only informal definition of the formula is supported.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::DerivedEnumerationParamDef -->
	<xsd:complexType name="DERIVED-ENUMERATION-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Derived value is an Enumeration.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:ENUMERATION-PARAM-DEF"/>
			<xsd:group ref="AR:DERIVED-PARAM-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::EnumerationParamDef -->
	<xsd:group name="ENUMERATION-PARAM-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Enumeration.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFAULT-VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Default value of the enumeration configuration parameter. This string nees to be one of the literals specified for this enumeration.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="LITERALS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="ENUMERATION-LITERAL-DEF" type="AR:ENUMERATION-LITERAL-DEF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::EnumerationParamDef -->
	<xsd:complexType name="ENUMERATION-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Enumeration.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:ENUMERATION-PARAM-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ECUCParameterDefTemplate::EnumerationLiteralDef -->
	<xsd:complexType name="ENUMERATION-LITERAL-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for enumeration literals definition.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ECUCParameterDefTemplate::DerivedFloatParamDef -->
	<xsd:complexType name="DERIVED-FLOAT-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Derived value is of type Float
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:FLOAT-PARAM-DEF"/>
			<xsd:group ref="AR:DERIVED-PARAM-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::FloatParamDef -->
	<xsd:group name="FLOAT-PARAM-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Float.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFAULT-VALUE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Default value of the float configuration parameter.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			max value allowed for the parameter defined.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			min value allowed for the parameter defined.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::FloatParamDef -->
	<xsd:complexType name="FLOAT-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Float.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:FLOAT-PARAM-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ECUCParameterDefTemplate::DerivedIntegerParamDef -->
	<xsd:complexType name="DERIVED-INTEGER-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Derived value is of type Integer.

		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:INTEGER-PARAM-DEF"/>
			<xsd:group ref="AR:DERIVED-PARAM-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::IntegerParamDef -->
	<xsd:group name="INTEGER-PARAM-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Integer.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFAULT-VALUE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Default value of the integer configuration parameter.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MAX" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			max value allowed for the parameter defined.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="MIN" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			min value allowed for the parameter defined.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::IntegerParamDef -->
	<xsd:complexType name="INTEGER-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Integer.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:INTEGER-PARAM-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ECUCParameterDefTemplate::DerivedStringParamDef -->
	<xsd:complexType name="DERIVED-STRING-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Derived value is of type String.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:STRING-PARAM-DEF"/>
			<xsd:group ref="AR:DERIVED-PARAM-TYPE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::StringParamDef -->
	<xsd:group name="STRING-PARAM-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for String.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFAULT-VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Default value of the string configuration parameter.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::StringParamDef -->
	<xsd:complexType name="STRING-PARAM-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for String.
		</xsd:documentation>
			<xsd:appinfo source="tags">
		   			xml.sequenceOffset="0"
		  	 </xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:STRING-PARAM-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::EcuParameterDefinition -->
	<xsd:group name="ECU-PARAMETER-DEFINITION">
		<xsd:annotation>
			<xsd:documentation>
			This represents the anchor point of an ECU Configuration Parameter Definition within the AUTOSAR templates structure.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MODULE-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MODULE-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:MODULE-DEF--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::EcuParameterDefinition -->
	<xsd:complexType name="ECU-PARAMETER-DEFINITION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This represents the anchor point of an ECU Configuration Parameter Definition within the AUTOSAR templates structure.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:ECU-PARAMETER-DEFINITION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::ModuleDef -->
	<xsd:group name="MODULE-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Used as the top-level element for configuration definition for Software Modules, including BSW and RTE as well as ECU Infrastructure.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="IMPLEMENTATION-CONFIG-VARIANT" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Used to define the actual implemented configuration variant in a specific &quot;vendor specific module definition&quot;, where it is mandatory.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="REFINED-MODULE-DEF-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODULE-DEF--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CONTAINERS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CHOICE-CONTAINER-DEF" type="AR:CHOICE-CONTAINER-DEF"/>
						<xsd:element name="PARAM-CONF-CONTAINER-DEF" type="AR:PARAM-CONF-CONTAINER-DEF"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::ModuleDef -->
	<xsd:complexType name="MODULE-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Used as the top-level element for configuration definition for Software Modules, including BSW and RTE as well as ECU Infrastructure.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:MODULE-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="MODULE-DEF--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MODULE-DEF"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUCParameterDefTemplate::ForeignReferenceDef -->
	<xsd:group name="FOREIGN-REFERENCE-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Specify a reference to an XML description of an entity desribed in another AUTOSAR template.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DESTINATION-TYPE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The type in the AUTOSAR Metamodel to which&apos; instance this reference is allowed to point to. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::ForeignReferenceDef -->
	<xsd:complexType name="FOREIGN-REFERENCE-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specify a reference to an XML description of an entity desribed in another AUTOSAR template.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:FOREIGN-REFERENCE-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ECUCParameterDefTemplate::FunctionNameDef -->
	<xsd:complexType name="FUNCTION-NAME-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Function Names like those used to specify callback functions.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:STRING-PARAM-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ECUCParameterDefTemplate::LinkerSymbolDef -->
	<xsd:complexType name="LINKER-SYMBOL-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Configuration parameter type for Linker Symbol Names like those used to specify memory locations of variables and constants.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:CONFIG-PARAMETER"/>
			<xsd:group ref="AR:STRING-PARAM-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::InstanceReferenceDef -->
	<xsd:group name="INSTANCE-REFERENCE-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Specify a reference to an XML description of an entity desribed in another AUTOSAR template using the INSTANCE REFERENCE semantics.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DESTINATION-CONTEXT" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The context in the AUTOSAR Metamodel to which&apos; this reference is allowed to point to.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="DESTINATION-TYPE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			The type in the AUTOSAR Metamodel to which&apos; instance this reference is allowed to point to. 
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::InstanceReferenceDef -->
	<xsd:complexType name="INSTANCE-REFERENCE-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specify a reference to an XML description of an entity desribed in another AUTOSAR template using the INSTANCE REFERENCE semantics.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:INSTANCE-REFERENCE-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCParameterDefTemplate::ReferenceDef -->
	<xsd:group name="REFERENCE-DEF">
		<xsd:annotation>
			<xsd:documentation>
			Specify references within the ECU Configuration Description between parameter containers.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DESTINATION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PARAM-CONF-CONTAINER-DEF--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCParameterDefTemplate::ReferenceDef -->
	<xsd:complexType name="REFERENCE-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Specify references within the ECU Configuration Description between parameter containers.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:REFERENCE-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ECUCParameterDefTemplate::SymbolicNameReferenceDef -->
	<xsd:complexType name="SYMBOLIC-NAME-REFERENCE-DEF" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This specialization of a ReferenceDef specifies that the implementation of the reference is done using a symbolic name defined by the referenced Container&apos;s shortName.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:PARAM-CONF-MULTIPLICITY"/>
			<xsd:group ref="AR:COMMON-CONFIGURATION-ATTRIBUTES"/>
			<xsd:group ref="AR:REFERENCE-DEF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCDescriptionTemplate::BooleanValue -->
	<xsd:group name="BOOLEAN-VALUE">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type BooleanParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:boolean" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Stores the value of the Boolean parameter.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::BooleanValue -->
	<xsd:complexType name="BOOLEAN-VALUE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type BooleanParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PARAMETER-VALUE"/>
			<xsd:group ref="AR:BOOLEAN-VALUE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUCDescriptionTemplate::ParameterValue -->
	<xsd:group name="PARAMETER-VALUE">
		<xsd:annotation>
			<xsd:documentation>
			Common class to all types of configuration values
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFINITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CONFIG-PARAMETER--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class ECUCDescriptionTemplate::ConfigReferenceValue -->
	<xsd:group name="CONFIG-REFERENCE-VALUE">
		<xsd:annotation>
			<xsd:documentation>
			Abstract class to be used as common parent for all reference values in the ECU Configuration Description.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFINITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:CONFIG-REFERENCE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- element group for class ECUCDescriptionTemplate::Container -->
	<xsd:group name="CONTAINER">
		<xsd:annotation>
			<xsd:documentation>
			Represents a Container definition in the ECU Configuration Description.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFINITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:PARAM-CONF-CONTAINER-DEF--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="PARAMETER-VALUES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="BOOLEAN-VALUE" type="AR:BOOLEAN-VALUE"/>
						<xsd:element name="ENUMERATION-VALUE" type="AR:ENUMERATION-VALUE"/>
						<xsd:element name="FLOAT-VALUE" type="AR:FLOAT-VALUE"/>
						<xsd:element name="FUNCTION-NAME-VALUE" type="AR:FUNCTION-NAME-VALUE"/>
						<xsd:element name="INTEGER-VALUE" type="AR:INTEGER-VALUE"/>
						<xsd:element name="LINKER-SYMBOL-VALUE" type="AR:LINKER-SYMBOL-VALUE"/>
						<xsd:element name="STRING-VALUE" type="AR:STRING-VALUE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="REFERENCE-VALUES" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="INSTANCE-REFERENCE-VALUE" type="AR:INSTANCE-REFERENCE-VALUE"/>
						<xsd:element name="REFERENCE-VALUE" type="AR:REFERENCE-VALUE"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="SUB-CONTAINERS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CONTAINER" type="AR:CONTAINER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::Container -->
	<xsd:complexType name="CONTAINER" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Represents a Container definition in the ECU Configuration Description.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:CONTAINER"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- complex type for class ECUCDescriptionTemplate::EcucElement -->
	<xsd:complexType name="ECUC-ELEMENT" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCDescriptionTemplate::EcuConfiguration -->
	<xsd:group name="ECU-CONFIGURATION">
		<xsd:annotation>
			<xsd:documentation>
			This represents the anchor point of the ECU configuration description.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="ECU-EXTRACT-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:SYSTEM--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="ECU-SW-COMPOSITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:ECU-SW-COMPOSITION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODULE-REFS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="MODULE-REF">
							<xsd:complexType>
								<xsd:simpleContent>
									<xsd:extension base="AR:REF">
										<xsd:attribute name="DEST" type="AR:MODULE-CONFIGURATION--SUBTYPES-ENUM" use="required"/>
									</xsd:extension>
								</xsd:simpleContent>
							</xsd:complexType>
						</xsd:element>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::EcuConfiguration -->
	<xsd:complexType name="ECU-CONFIGURATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			This represents the anchor point of the ECU configuration description.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:ECU-CONFIGURATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<!-- element group for class ECUCDescriptionTemplate::ModuleConfiguration -->
	<xsd:group name="MODULE-CONFIGURATION">
		<xsd:annotation>
			<xsd:documentation>
			Head of the configuration of one Module. A Module can be a BSW module as well as the RTE and ECU Infrastructure.

As part of tthe BSW module description, the ModuleConfiguration has two different roles:

The recommendedConfiguration contains parameter values recommended by the BSW module vendor. 

The preconfiguredConfiguration contains values for those parameters which are fixed by the implementation and cannot be changed.

These two ModuleConfigurations are used when the base ModuleConfiguration (as part of the base ECU configuration) is created to fill parameters with initial values.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="DEFINITION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODULE-DEF--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="MODULE-DESCRIPTION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:BSW-MODULE-DESCRIPTION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="CONTAINERS" minOccurs="0">
				<xsd:complexType>
					<xsd:choice minOccurs="0" maxOccurs="unbounded">
						<xsd:element name="CONTAINER" type="AR:CONTAINER"/>
					</xsd:choice>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::ModuleConfiguration -->
	<xsd:complexType name="MODULE-CONFIGURATION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Head of the configuration of one Module. A Module can be a BSW module as well as the RTE and ECU Infrastructure.

As part of tthe BSW module description, the ModuleConfiguration has two different roles:

The recommendedConfiguration contains parameter values recommended by the BSW module vendor. 

The preconfiguredConfiguration contains values for those parameters which are fixed by the implementation and cannot be changed.

These two ModuleConfigurations are used when the base ModuleConfiguration (as part of the base ECU configuration) is created to fill parameters with initial values.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:MODULE-CONFIGURATION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="MODULE-CONFIGURATION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="MODULE-CONFIGURATION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- element group for class ECUCDescriptionTemplate::EnumerationValue -->
	<xsd:group name="ENUMERATION-VALUE">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type EnumerationParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Stores the chosen literal.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::EnumerationValue -->
	<xsd:complexType name="ENUMERATION-VALUE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type EnumerationParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PARAMETER-VALUE"/>
			<xsd:group ref="AR:ENUMERATION-VALUE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUCDescriptionTemplate::FloatValue -->
	<xsd:group name="FLOAT-VALUE">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type FloatParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:double" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Stores the value of the Float parameter.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::FloatValue -->
	<xsd:complexType name="FLOAT-VALUE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type FloatParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PARAMETER-VALUE"/>
			<xsd:group ref="AR:FLOAT-VALUE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ECUCDescriptionTemplate::FunctionNameValue -->
	<xsd:complexType name="FUNCTION-NAME-VALUE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type FunctionNameDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PARAMETER-VALUE"/>
			<xsd:group ref="AR:STRING-VALUE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- complex type for class ECUCDescriptionTemplate::LinkerSymbolValue -->
	<xsd:complexType name="LINKER-SYMBOL-VALUE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type LinkerSymbolDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PARAMETER-VALUE"/>
			<xsd:group ref="AR:STRING-VALUE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUCDescriptionTemplate::StringValue -->
	<xsd:group name="STRING-VALUE">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type StringParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:string" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Stores the value of the String parameter.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::StringValue -->
	<xsd:complexType name="STRING-VALUE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type StringParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PARAMETER-VALUE"/>
			<xsd:group ref="AR:STRING-VALUE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUCDescriptionTemplate::InstanceReferenceValue -->
	<xsd:group name="INSTANCE-REFERENCE-VALUE">
		<xsd:sequence>
			<xsd:element name="VALUE-IREF" type="AR:INSTANCE-REFERENCE-VALUE--VALUE-IREF" minOccurs="0"/>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::InstanceReferenceValue -->
	<xsd:complexType name="INSTANCE-REFERENCE-VALUE" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:CONFIG-REFERENCE-VALUE"/>
			<xsd:group ref="AR:INSTANCE-REFERENCE-VALUE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUCDescriptionTemplate::IntegerValue -->
	<xsd:group name="INTEGER-VALUE">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type IntegerParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Stores the value of the Integer parameter.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::IntegerValue -->
	<xsd:complexType name="INTEGER-VALUE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Representing a configuration value of definition type IntegerParamDef
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:PARAMETER-VALUE"/>
			<xsd:group ref="AR:INTEGER-VALUE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class ECUCDescriptionTemplate::ReferenceValue -->
	<xsd:group name="REFERENCE-VALUE">
		<xsd:annotation>
			<xsd:documentation>
			Used to represent a configuration value that has a parameter definition of type ConfigReference (used for all of its specializations excluding InstanceReferenceDef).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="VALUE-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:IDENTIFIABLE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class ECUCDescriptionTemplate::ReferenceValue -->
	<xsd:complexType name="REFERENCE-VALUE" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Used to represent a configuration value that has a parameter definition of type ConfigReference (used for all of its specializations excluding InstanceReferenceDef).
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:CONFIG-REFERENCE-VALUE"/>
			<xsd:group ref="AR:REFERENCE-VALUE"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class _instanceRef::InstanceReferenceValue_value -->
	<xsd:group name="INSTANCE-REFERENCE-VALUE--VALUE-IREF">
		<xsd:sequence>
			<xsd:element name="CONTEXT-REF" minOccurs="0" maxOccurs="unbounded">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:IDENTIFIABLE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="VALUE-REF">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:IDENTIFIABLE--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class _instanceRef::InstanceReferenceValue_value -->
	<xsd:complexType name="INSTANCE-REFERENCE-VALUE--VALUE-IREF" abstract="false" mixed="false">
		<xsd:sequence>
			<xsd:group ref="AR:INSTANCE-REFERENCE-VALUE--VALUE-IREF"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
	</xsd:complexType>
	<!-- element group for class BswModuleTemplate::BswModuleDescription -->
	<xsd:group name="BSW-MODULE-DESCRIPTION">
		<xsd:annotation>
			<xsd:documentation>
			Root element for the description of a single BSW module or a module cluster.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="MODULE-ID" type="xsd:integer" minOccurs="0">
				<xsd:annotation>
					<xsd:documentation>
			Refers to the BSW Module Identifier defined by the AUTOSAR standard.
		</xsd:documentation>
				</xsd:annotation>
			</xsd:element>
			<xsd:element name="PRECONFIGURED-CONFIGURATION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODULE-CONFIGURATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="RECOMMENDED-CONFIGURATION-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODULE-CONFIGURATION--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="VENDOR-SPECIFIC-MODULE-DEF-REF" minOccurs="0">
				<xsd:complexType>
					<xsd:simpleContent>
						<xsd:extension base="AR:REF">
							<xsd:attribute name="DEST" type="AR:MODULE-DEF--SUBTYPES-ENUM" use="required"/>
						</xsd:extension>
					</xsd:simpleContent>
				</xsd:complexType>
			</xsd:element>
		</xsd:sequence>
	</xsd:group>
	<!-- complex type for class BswModuleTemplate::BswModuleDescription -->
	<xsd:complexType name="BSW-MODULE-DESCRIPTION" abstract="false" mixed="false">
		<xsd:annotation>
			<xsd:documentation>
			Root element for the description of a single BSW module or a module cluster.
		</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:group ref="AR:IDENTIFIABLE"/>
			<xsd:group ref="AR:BSW-MODULE-DESCRIPTION"/>
		</xsd:sequence>
		<xsd:attributeGroup ref="AR:AR-OBJECT"/>
		<xsd:attributeGroup ref="AR:IDENTIFIABLE"/>
	</xsd:complexType>
	<xsd:simpleType name="BSW-MODULE-DESCRIPTION--SUBTYPES-ENUM">
		<xsd:restriction base="xsd:string">
			<xsd:enumeration value="BSW-MODULE-DESCRIPTION"/>
		</xsd:restriction>
	</xsd:simpleType>
	<!-- Predefined element and attribute types -->
	<xsd:simpleType name="IDENTIFIER">
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="[a-zA-Z][a-zA-Z0-9_]{0,31}"/>
		</xsd:restriction>
	</xsd:simpleType>
	<xsd:simpleType name="REF">
		<xsd:restriction base="xsd:string">
			<xsd:pattern value="(/[a-zA-Z][a-zA-Z0-9_]{0,31})*"/>
			<!-- Pattern:
				 - first slash optional (relative or absolute reference)
				 - Identifier consisting of [letter][letter|digit|underscore] required
				 - optionally a sequence of slashes and Identifiers
			-->
		</xsd:restriction>
	</xsd:simpleType>
</xsd:schema>
